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FOREWORD 


In  this  monograph,  Ms.  Elizabeth  A.  Stanley  analyzes 
developments  in  the  Army  Tactical  Command  and  Control 
System  as  a  vehicle  for  assessing  the  U.S.  Army’s  strate^ 
for  exploiting  information  age  technologies.  Her  analysis 
will  be  of  great  value  to  those  interested  in  several 
dimensions  of  military  modernization,  in  particular 
whether  we  are  amid  a  revolution  in  military  affairs  (RMA) 
or  something  less  profound.  If  it  is  an  RMA,  then  how  well 
are  we  in  the  Army  seizing  the  opportunities  it  presents? 

Ms.  Stanley  takes  the  reader  through  the  evolution  of 
the  Army’s  efforts  to  harness  the  microchip  to  its  command 
and  control  system.  While  the  account  is  interesting  in  its 
own  right,  the  lessons  she  derives  from  it  have  the  greatest 
value  to  us  today  as  we  consider  the  next  chapter  in  the 
Army’s  development. 

Ms.  Stanley  sees  Force  XXI  more  as  the  latest  phase  in  a 
decades-long  process  than  a  new  beginning.  She  points  out, 
for  instance,  that  despite  the  Force  XXI  initiatives  inspired 
by  former  Army  Chief  of  Staff  Gordon  R.  Sullivan,  which 
seem  to  be  coming  to  fruition,  the  Army  has  not  altered  its 
core  tasks  nor  displaced  any  of  its  combat  platforms. 
Changes  largely  have  been  marginal,  revolving  around  the 
leveraging  of  technologies  into  existing  systems. 

The  deeper  message  here  is  that  technological  change, 
evolutionary  and  revolutionary,  does  not  just  happen.  It 
requires  the  vision  of  leadership,  corporate  acceptance,  and 
managerial  genius  to  guide  it  to  effective  implementation. 
The  strength  of  the  Army  is  that  it  has  become  the  world’s 
finest  land  force  by  openly  discussing  not  only  its  vision  for 
the  future,  but  also  the  processes  by  which  it  has  gotten  to 
where  it  is  today  and  where  it  intends  to  be  tomorrow. 
Therefore,  I  commend  to  you  Ms.  Stanleys  paper  precisely 
because  she  has  taken  a  somewhat  cautionary  view  of  the 
path  along  which  the  Army  is  proceeding. 
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Ms.  Stanley,  a  former  Army  captain  and  currently  a 
doctoral  candidate  in  the  Department  of  Government  at 
Harvard  University,  originally  wrote  this  paper  as  part  of  a 
grant  provided  by  the  National  Science  Foundation. 
Subsequently,  Women  In  International  Security  (WHS) 
conveyed  their  Best  Paper  of  1997  Award  on  Ms.  Stanley  at 
WlIS’s  Annual  Summer  Symposium  for  Graduate  Students 
in  International  Affairs. 


RICHARD  H.  WETHERSPOON 

Colonel,  U.S.  Army 

Director,  Strategic  Studies  Institute 
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EVOLUTIONARY  TECHNOLOGY 
IN  THE  CURRENT  REVOLUTION 
IN  MILITARY  AFFAIRS: 

THE  ARMY  TACTICAL  COMMAND 
AND  CONTROL  SYSTEM 


I  see  ...  an  integrated  area  control  system  that  exploits  the 
advanced  technology  of  communications,  sensors,  fire  direction 
and  automatic  data  processing. . . .  Enemy  forces  will  be  located, 
tracked,  and  targeted  almost  instantaneously  through  use  of 
data  links,  computer  assisted  intelligence  evaluation  and 
automated  fire  control —  With  cooperative  effort,  no  more  than 
ten  years  should  separate  us  from  the  automated  battlefield.^ 

It’s  a  grand  blueprint  for  a  revolutionary  concept  of  land 
warfare.  Visionary.  Dynamic.  And  it’s  almost  here — only  20 
years  late.  In  1969  then  Chief  of  Staff  of  the  Army  General 
William  C.  Westmoreland  described  this  vision  of  an 
automated  battlefield  at  a  meeting  of  the  Association  of  the 
United  States  Army.  Thirty  years  and  bilhons  of  dollars 
later,  the  U.S.  Army  is  still  waiting  for  his  dream  to  become 
reality.  The  saga  of  the  Army’s  efforts  to  automate  tactical 
command  and  control  spans  decades  and  serves  as  a 
fascinating  case  study  for  a  theoretical  inquiry  about 
innovation  in  military  organizations.  Moreover,  the  Army 
Tactical  Command  and  Control  System — or  ATCCS,  as  this 
automated  system  became  known — can  provide  some  useful 
insights  into  the  contemporary  Revolution  in  Military 
Affairs  (RMA),  whose  status  continues  to  be  debated  by 
scholars  and  soldiers  alike.  I  argue  that  although  ATCCS 
had  the  potential  to  be  a  revolutionary  innovation,  various 
aspects  of  its  development  process  and  the  Army’s 
procurement  process  have  caused  it  to  miss  its  mark. 

ATCCS  was  designed  to  become  the  principal  command 
and  control  focus  within  a  theater  of  military  operations. 
The  plan  envisioned  respective  control  systems  for  the  five 
battlefield  functional  areas  (BFAs) — maneuver,  fire 
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support,  air  defense  artillery,  intelligence/electronic 
warfare,  and  combat  service  support — and  three  primary 
communications  systems.  Through  the  use  of  common 
hardware  and  software,  each  BFA  was  to  manage, 
coordinate  and  process  information  internally.  Force  Level 
Control  was  to  provide  the  mechanism  for  the  commander 
and  staff  to  coordinate  horizontally  among  the  BFAs  at  each 
level,  as  well  as  for  the  BFAs  to  coordinate  vertically  among 
echelons. 

This  paper  is  divided  into  seven  sections.  The  first 
section  outlines  the  theoretical  considerations  for 
innovation  in  military  organizations,  while  the  second 
section  explains  the  concept  of  the  current  RMA  in  greater 
detail.  The  third  section  recounts  the  first  three  generations 
in  the  family  of  automated  command  and  control  (C^) 
systems  which  eventually  became  known  as  ATCCS.  In  the 
fourth  section,  I  argue  that  the  development  of  this 
intellectual  vision  culminated  with  the  fourth  generation,  a 
system  called  Sigma  Star.  The  fifth  section  outlines  the 
development  of  ATCCS  until  the  Gulf  War.  Some  of  the 
ATCCS  systems  were  deployed  in  DESERT  STORM  with 
mixed  results,  as  the  sixth  section  will  show.  After  the 
performance  in  DESERT  STORM,  a  heightened  interest  in 
battlefield  situational  awareness  catalyzed  a  top-down 
Army  reorganization  effort,  led  by  then-Chief  of  Staff  of  the 
Army  General  Gordon  Sullivan.  The  first  half  of  the  sixth 
section  describes  Sullivan’s  vision  of  Force  XXI  and  its 
implications  for  ATCCS.  Although  Force  XXI  involved  a 
serious  image  overhaul  of  the  Army’s  battlefield 
digitization,  the  successor  to  ATCCS — called  the  Army 
Battle  Command  System  (ABCS) — added  little  value  to  the 
previous  Sigma  Star  paradigm.  The  Army  tested  ABCS  in 
March  1997  in  a  brigade-level  Advanced  Warfighting 
Experiment  at  the  National  Training  Center;  the  second 
half  of  the  sixth  section  describes  some  preliminary 
results — ^from  the  perspective  of  several  participants — of 
this  experiment.  The  final  section  analyzes  ATCCS  in  light 
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of  innovation  theory  and  draws  some  implications  for  the 
current  RMA. 

Theoretical  Considerations. 

Before  deciding  whether  ATCCS  is  a  component  of  the 
current  RMA,  or  even  if  it  is  a  military  innovation  in 
general,  it  is  necessary  to  define  these  terms.  In  the 
theoretical  literature  about  military  innovation,  authors’ 
viewpoints  diverge  in  two  areas:  the  definition  itself — what 
is  military  innovation? — and  its  underlying  causal 
forces— what  causes  military  innovation?  This  section  will 
briefly  review  the  relevant  literature  and  offer  working 
definitions  of  "military  innovation”  and  RMA;  the  major 
hypotheses  from  this  literature  will  then  become  the 
standards  against  which  ATCCS  will  be  compared. 

Most  authors  differentiate  between  tyipes  of  innova¬ 
tion — peacetime  versus  wartime,  technological  versus 
doctrinal,  evolutionary  versus  revolutionary.  To  simplify 
the  process,  it  makes  sense  to  focus  around  Wilson’s  elegant 
definition  that  "real  innovations  are  those  that  alter  core 
tasks.”^  This  definition  is  echoed  by  Rosen  and  Cote,  who 
focus  somewhat  more  carefully  on  the  parts  of  the 
organization  performing  the  tasks.  According  to  Rosen,  a 
major  military  innovation  is  defined  as: 

a  change  in  one  of  the  primary  combat  arms  of  a  service  in  the 
way  that  it  fights  or  alternatively,  as  the  creation  of  a  new 

combat  arm A  maj or  innovation  also  involves  a  change  in  the 

relation  of  that  combat  arm  to  other  combat  arms  and  a 
downgrading  or  abandoning  of  older  concepts  of  operations  and 
possibly  of  a  formerly  dominant  weapon.^ 

Cote  makes  the  same  point  by  calling  innovation  a  "major 
change  in  the  division  of  labor”  among  the  combat  arms.^ 
Both  authors  define  a  combat  arm  as  a  "functional  division” 
or  "platform  community”  within  a  service,  oriented  around  a 
particular  weapon  system.  Thus,  these  three  definitions  of 
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military  innovation  share  a  focus  on  doctrinal  or  organiza¬ 
tional — ^rather  than  technological — change. 

For  a  military  innovation  also  to  be  labeled  a  “Revolution 
in  Military  Affairs,”  it  must  combine  a  new  technology  with 
the  doctrinal  or  operational  change  of  the  three  definitions 
above.  Most  authors  agree  that  an  RMA  is  only  possible 
through  the  synthesis  of  technological  and  doctrinal 
innovations;  Hayes  and  Gardiner  both  talk  of  a  “marriage 
between  doctrine  and  technology.”®  Krepinevich  argues 
that  newly  emerging  technologies  can  make  an  RMA 
possible,  but  technological  innovation  alone  cannot  spark 
an  RMA.  “To  realize  their  full  potential,  these  technologies 
t3rpically  must  be  incorporated  within  new  processes  and 
executed  by  new  organizational  structures.”®  In  other 
words,  technology  is  a  necessary  but  not  a  sufficient 
condition  for  an  RMA.  Or  as  Cordesman  points  out,  “He  who 
dies  with  the  most  toys  simply  dies,  he  does  not  win. 
Technology  will  only  be  valuable  to  the  extent  it  is 
integrated  into  an  effective  overall  force  structure.”^ 

Libicki  and  Hazlett  use  the  term  “Military-Technical 
Revolution”  (MTR)  to  clarify  this  distinction:  a 
military-technical  revolution  is  the  impact  of  a  new 
technology  on  warfare,  while  an  RMA  encompasses  the 
subsequent  transformation  of  operations  and  organization.® 
Similarly,  Fitzsimmons  and  Van  Tolz  suggest  that  there  are 
three  preconditions  necessary  for  the  full  realization  of  an 
RMA:  technological  development,  doctrinal  innovation,  and 
organizational  adaptation.®  Cooper’s  list  is  essentially  the 
same,  except  that  he  divides  the  concept  into  four 
components:  evolving  military  systems,  emerging 
technology,  operational  innovation,  and  organizational 
adaptation.^®  Thus — while  authors  disagree  whether 
doctrinal  or  technological  innovation  is  causally 
prior — there  is  consensus  that  both  components  are 
necessary  for  an  RMA.  By  differentiating  an  RMA  from  an 
MTR,  it  places  increasing  importance  on  doctrinal  and 
operational  innovation  and  less  importance  on  the 
technology.  As  Metz  and  Kievit  note: 
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The  basic  premise  of  the  RMA  is  clear:  throughout  history, 
warfare  usually  developed  in  an  evolutionary  fashion,  but 
occasionally  ideas  and  inventions  combined  to  propel  dramatic 
and  decisive  change.  This  not  only  affected  the  application  of 
military  force,  but  often  altered  the  geopolitical  balance  in  favor 
of  those  who  mastered  the  new  form  of  warfare.^^ 

In  sum,  for  the  purposes  of  this  paper,  a  “military 
innovation”  is  the  doctrinal,  operational,  or  organizational 
innovation  to  which  Rosen,  Cote,  and  Wilson  refer.  A 
“Military-Technical  Revolution”  describes  cases  where 
technology  is  the  predominant  factor  in  innovation, 
especially  when  technology  is  employed  in  an  evolutionary 
manner,  without  causing  doctrinal  or  organizational 
change.  In  this  way,  my  definition  for  MTR  resembles  Cote’s 
definition  for  “evolution.”  Finally,  a  “Revolution  in  Mihtary 
Affairs”  combines  these  first  two  concepts  S3mergistically; 
technological,  doctrinal,  and  organizational  innovation 
must  all  be  present  for  an  RMA  to  occur. 

With  these  definitions  in  mind,  it  is  easy  to  understand 
why  many  scholars  argue  that  military  organizations  resist 
innovation.  As  Rosen  points  out,  large  bureaucracies  are  not 
only  difficult  to  change,  they  are  explicitly  designed  not  to 
change — “the  absence  of  innovation  is  the  rule,  the  natural 
state. Posen  agrees  that  military  innovation  is  rare  for 
two  reasons.  First,  the  process  of  institutionalization  gives 
most  members  a  stake  in  the  ways  things  are  currently 
organized.  Second,  innovation  will  increase  operational 
uncertainty,  the  one  thing  that  large  organizations  hope  to 
minimize. Wilson  argues  that  this  resistance  to 
innovation  is  even  stronger  in  military  organizations  than 
in  other  bureaucracies,  because  members  have  a  strong 
sense  of  mission  and  face  greater  penalties  for  operational 
uncertainty.  Thus  he  posits  that  military  organizations  will 
accept — or  at  least  not  bitterly  resist— -“innovations  that 
facilitate  performance  of  existing  tasks  in  a  way  that  is 
consistent  with  existing  managerial  arrangements.”  This 
bias  towards  maintaining  the  existing  task  definitions  can 
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lead  the  organization  to  adopt  new  technology  without 
understanding  its  significance.^^ 

If  military  innovation  is  such  a  rare  occurrence,  what 
causes  it?  The  hterature  offers  numerous  explanations — 
including  external  threat,  civilian  intervention,  inter-  and 
intra-service  rivalry,  individuals  and  war  or  peace.  The  five 
themes  are  separated  here  for  the  sake  of  clarity,  but  this 
artificial  division  does  not  minimize  the  correlation  among 
them. 

First,  authors  diverge  on  the  importance  of  an  external 
threat  as  a  cause  of  innovation.  The  biggest  supporter  of 
external  threat  is  perhaps  Posen,  who  argues  that  when 
threats  rise,  the  military  loses  its  operational  autonomy  as 
civilians  intervene  to  "repair”  the  organization.  Increased 
threat  will  increase  civilian  intervention,  but  "soldiers  tend 
to  be  more  amenable  to  external  prodding  when  threat  of 
war  looms  larger.”  This  is  especially  hkely  in  "politically 
isolated  or  geographically  surrounded  states”  which  are 
more  vulnerable.^^  Another  supporter  is  Cote,  who  asserts 
that  mihtary  innovation  must  occur  during  high  threat  and 
a  perception  of  low  resource  availability  to  balance  against 
the  threat.  In  contrast,  Rosen  places  very  little  importance 
on  external  threat  in  innovation. 

The  second  cause  of  innovation  is  civilian  intervention. 
Posen  concludes  that  civilian  intervention  is  most  likely 
during  high  external  threat,  after  military  defeat,  or  in 
preparation  for  national  expansionism.  The  literature  is 
divided  into  two  types  of  civilian  intervention.  The  first 
relates  to  funding  constraints — which  Cote  calls  the 
"domestic  pohtical  economy  of  the  defense  budget.”  Many 
authors — ^including  Fitzsimmons  and  Van  Tolz,  Cote,  and 
Posen — argue  that  shrinking  budgets  will  cause  civihans  to 
intervene  and  prioritize  defense  dollars.  Alternatively,  the 
political  leaders  may  cause  the  services  to  fight  it  out  among 
themselves.  The  second  type  of  civilian  intervention, 
technology  transfer,  is  more  subtle.  As  Krepinevich  argues, 
the  technologies  that  eventually  cause  military  innovations 
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and  RMAs  are  often  originally  developed  outside  of  the 
military  and  then  "imported  and  exploited  for  their  military 
applications.”^®  This  is  even  more  important  with  the 
current  RMA,  because  in  the  1980s  the  main  arena  for 
technological  innovation  shifted  from  the  government  to  the 
commercial  sector. 

The  third  cause,  inter-  and  intra-service  rivalry,  follows 
directly  from  civilian  intervention.  Hayes  argues  that 
inter-service  rivalry  stimulates  innovation,  especially  in 
response  to  Congressional  control  of  the  purse  strings.^®  In 
contrast,  Rosen  focuses  more  on  intra-service  ideological 
struggles  over  a  "new  theory  of  victory.”  This  ideological 
struggle  occurs  within  different  leadership  cliques  of  the 
same  service,  as  senior  leaders  try  to  advance  their 
particular  intellectual  and  operational  vision.^® 

Rosen’s  concept  of  an  ideological  struggle  relates  to  the 
fourth  cause  of  innovation:  individuals.  As  Hayes  points 
out,  "people,  not  organizational  arrangements,  make  the 
greatest  difference  to  innovation.”^®  Although  many 
authors  agree  that  individuals  are  important  in  the 
innovative  process,  their  views  diverge  about  which 
individuals.  Rosen  asserts  that  innovation  must  come  from 
the  top-down  influence  of  senior  military  leaders,  who 
accept  that  the  nature  of  conflict  is  undergoing  fundamental 
change.  Then,  Rosen  argues,  if  "military  leaders  . . .  attract 
talented  young  officers  with  great  potential  for  promotion  to 
a  new  way  of  war,  and  then  . . .  protect  and  promote  them, 
they  [can]  produce  new,  usable  military  capabilities.”^^ 
Wilson  seconds  the  importance  of  executive  leaders  in 
explaining  change.  He  cites  a  study  which  found  that  top 
executives’  beliefs  were  better  predictors  of  change  than  any 
structural  features  of  the  organization.  However,  because 
"innovations  are  so  heavily  dependent  on  executive 
interests  and  beliefs  as  to  make  the  chance  appearance  of  a 
change-oriented  personality  enormously  important,” 
Wilson  argues  that  it  is  extremely  difficult  to  specify  a 
theory  of  innovation.^^  Finally,  Posen  argues  that  military 
mavericks  can  be  important  in  assisting  civilian  inter- 
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vention  by  propagating  interest  in  the  technological 
innovation. 

Finally,  the  theories  diverge  on  the  issue  of  whether 
innovation  is  more  successful  during  war  or  peace.  Rosen 
supports  peacetime  as  being  more  fruitful  for  military 
innovation.  He  suggests  that  peacetime  military  innovation 
occurs  when  respected  senior  military  officers  formulate  a 
"new  theory  of  victory”  with  intellectual  and  organizational 
components.  Not  only  is  this  kind  of  ideological  debate 
difficult  to  conduct  during  war,  but  lack  of  precedent  also 
makes  wartime  innovation  risky  and  infrequent.  Rosen 
argues  that  when  mihtary  innovation  is  required  during 
war,  it  is  because  the  nation  is  pursuing  inappropriate 
strategic  goals  or  the  military  has  misunderstood  the 
strategic  goals.^^  Fitzsimmons  and  Van  Tolz  agree  that 
militaries  are  driven  to  innovate  during  peacetime  because 
"it  is  the  period  of  least  risk  if  wrong  choices  are  made. 
Consequently,  long  periods  without  major  wars  have 
generally  resulted  in  the  greatest  changes. In  contrast, 
Posen  argues  that  technology  tested  through  direct  combat 
experience — by  a  client  state  or  better  yet  by  a  state 
itself— can  cause  innovation.  New  technology  that  is  not 
employed  in  a  war  is  less  likely  to  serve  as  a  catalyst  for 
doctrinal  or  organizational  change.  Wars  can  also  increase 
innovation  if  a  military  suffers  defeat,  because  such  failure 
will  alert  civilians  that  something  is  broken  and  needs 
fixing.^® 

Overall,  Posen  concludes  that  innovation  comes  from 
outside  the  military  through  civilian  intervention,  espe¬ 
cially  during  periods  of  high  threat,  after  military  defeat  or 
in  preparation  for  national  expansionism.  Rosen  asserts 
that  it  comes  from  within  the  military  through  top-down 
influence  of  senior  military  leaders.  Cote  argues  that 
military  innovation  is  most  likely  during  high  threat  and 
accompanied  by  the  perception  of  limited  resources  with 
which  to  balance  against  the  threat.  In  general,  no  one 
theory  of  innovation  has  been  proven  dominant.  The  fact 
that  each  author  cites  different  cases  in  his  work 
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demonstrates  that  innovation  occurs,  albeit  rarely,  but  that 
no  single  cause  can  be  identified.  Therefore,  all  of  these 
hypotheses  will  be  kept  in  mind  during  the  analysis  of 
ATCCS. 


The  Current  RMA. 

The  notion  of  military  revolutions  grew  from  Soviet 
writing  of  the  1970s  and  1980s.  Early  studies  talked  of  a 
“military  technical  revolution,”  but  this  quickly  developed 
into  the  more  holistic,  synergistic  concept  of  an  RMA. 
Despite  divergent  views  on  military  revolutions  in  general 
as  outlined  above,  analysts  agree  overall  about  the  defining 
characteristics  and  components  of  the  current  RMA.  The 
current  RMA,  which  some  analysts  believe  is  already  more 
than  20  years  old,  developed  as  the  result  of  precision 
weaponry  linked  with  knowledge. 

The  emerging  RMA  in  mid-  to  high-intensity  warfare  is  centered 
around  the  fusion  of  sophisticated  remote  sensing  systems  with 
extremely  lethal,  usually  stand-off  precision-strike  weapons 
and  automation-assisted  command,  control  and  communi¬ 
cations.  .  .  .  This  fusion  is  expected  to  allow  smaller  military 
forces  to  attain  rapid,  decisive  results  through  synchronized, 
near-simultaneous  operations  throughout  the  breadth  and 
depth  of  a  theater  of  war.^® 

Admiral  William  A.  Owens,  the  former  Vice  Chairman  of 
the  Joint  Chiefs  of  Staff,  asserts  that  the  technological 
innovations  of  the  current  RMA  fall  into  three  categories: 
intelligence,  surveillance  and  reconnaissance  (ISR); 
advanced  C^I  (command,  control,  communications, 
computers  and  intelligence);  and  precision  force  weapons. 
These  three  technologies  together  will  form  a  “system  of 
systems.”^^  “Fusing  and  processing  information — making 
sense  of  the  vast  amounts  of  data  that  can  be  gathered — ^will 
give  U.S.  forces  what  is  called  dominant  battlespace 
knowledge,  a  wide  asvmmetry  between  what  Americans 
and  opponents  know.”  ° 
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Scholars  generally  concur  that  the  current  RMA  has  four 
defining  characteristics.  The  first — precise,  stand-off 
conventional  strikes — ^is  the  least  radical  of  the  capabilities 
associated  with  the  RMA.  Mazarr  calls  this  “disengage¬ 
ment,”  or  the  process  of  conducting  military  operations  at  a 
significant  distance  from  the  enemy.  As  Mazarr  theorizes, 
disengagement  has  three  larger  implications.  First, 
disengaged  combat  will  reduce  U.S.  force  attrition  and  hold 
casualty  rates  down.  Second,  it  may  create  a  hierarchy  in 
enemy  targets,  such  that  enemy  weapons  with  the  longest 
ranges  will  be  targeted  first,  because  longer  range  weapons 
will  have  the  furthest  reach  against  us.  Finally,  it  will  place 
a  premium  on  long-distance  systems  and  will  fiirther  “the 
trend  toward  the  decline  in  importance  of  heavy, 
mechanized  ground  forces.”^^ 

The  second  characteristic  of  the  current  RMA  is  an 
increasing  interest  in  information  dominance.  Many 
analysts  within  the  military  view  information  dominance  as 
an  adjunct  to  conventional  warfare  or  as  a  force  multiplier. 
Perhaps  the  most  widely-quoted  concept  is  Air  Force 
Colonel  John  Boyd’s  observation-orientation-decision- 
action  (OODA)  loop,  which  refers  to  the  C^I  network.  Using 
the  OODA  loop  offensively,  a  military  can  “enmesh  [its] 
adversary  in  a  world  of  uncertainty,  doubt,  mistrust, 
confusion,  disorder,  fear,  panic,  chaos. . . .  and/or  fold  [him] 
back  inside  himself  so  that  he  cannot  cope  with  events/ 
efforts  as  they  unfold.”  The  real  objective  is  to  complete  the 
fnendly  OODA  cycle  faster  than  the  adversary  can  complete 
his.^^  Fundamentally,  this  requires  that  a  military 
organization  have  a  doctrine  for  handling  and  processing 
information  and  empowering  commanders  with  fused, 
real-time  knowledge  about  the  battlefield. 

Some  analysts  view  information  as  more  than  simply  a 
tool  for  operational  control  and  increasingly  consider  it  a 
strategic  asset.  This  is  a  much  broader  view  of  information 
dominance,  reflecting  Alvin  and  Heidi  Toffier’s  view  that 
information  is  becoming  the  basis  of  economic  strength.  The 
Tofflers  describe  history  as  progressing  through  a  series  of 
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waves;  each  wave  and  its  wars  are  based  on  the  means  by 
which  wealth  is  created.  Thus,  in  their  neo-Marxist  view, 
during  the  "First  Wave”  of  human  development,  production 
was  primarily  agricultural,  so  war  sought  to  seize  and  hold 
territory.  During  the  "Second  Wave,”  industrial  production 
dominated,  so  war  was  a  struggle  of  attrition  in  which 
opponents  sought  to  wear  down  each  other’s  capacity  to  feed 
and  equip  mass  armies.  Following  this  logic,  "Third  Wave” 
warfare  will  seek  to  erode  or  destroy  the  enemy’s  means  of 
collecting,  processing,  storing,  and  disseminating  informa¬ 
tion.^^  There  are  some  significant  problems  with  their 
simplistic  argument,  not  the  least  that  the  Third  Wave 
seems  still  to  be  depending  on  Second  Wave  industrial-era 
economics  and  wealth-creation  processes.^^  Despite  factual 
inaccuracies  and  little  attention  in  the  scholarly  literature, 
the  Tofflers’  book  has  received  tremendous  attention  from 
within  the  government  and  is  required  reading  in  the 
curricula  of  three  service  war  colleges.^^ 

The  third  characteristic  of  the  current  RMA  is  "synergy,” 
or  "jointness”  to  use  the  more  common  term.  In  this  context, 
S5niergy  is  intimately  related  to  information  dominance. 
Communication  is  essential  for  synergy  to  exist,  which 
requires  that  all  American  military  services — as  well  as 
those  of  our  allies — ^have  the  ability  to  communicate  on 
integrated,  inter-operable  systems.  Integrated  C'^I  systems 
are  only  the  beginning  of  a  broader  integration  between  the 
services’  missions  and  roles.  Mazarr  posits  that  "over  time, 
the  evolution  of  synergy  within  the  military  .  .  .  might 
overwhelm  the  current  roles  and  missions  debate.  .  .  . 
Synergy  should  not  be  perceived  as  rooting  out  all  aspects  of 
redundancy,  but  rather  making  the  various  forces  work 
better  together.”^® 

The  final  characteristic  associated  with  the  current 
RMA  is  civilianization.  This  characteristic  encompasses 
two  aspects:  a  reduction  in  the  number  of  casualties  and 
collateral  damage  associated  with  military  combat 
operations,^^  and  a  blurring  of  the  distinction  between 
military  and  civilian  endeavors.  "Future  warfare  will  be 
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information  warfare,  and  it  is  therefore  built  upon  a 
foundation  of  civilian  technologies.”^®  Simply  stated, 
warfare  is  the  practice  of  focusing  the  state’s  power  in  a 
particular  direction  to  achieve  strategic  goals.  Throughout 
history,  this  has  usually  been  accomphshed  by  appl5dng 
armed  formations  to  achieve  the  purposes  of  warfare. 
Civilianization  suggests  that  new  technologies  may  require 
a  state  to  bring  nonstandard  actors  into  the  conduct  of 
warfare.  This  in  turn  may  change  the  definition  of  a 
“warrior”  or  “warrior  culture”  so  that  those  sitting  behind 
computer  screens  are  making  a  more  direct  contribution  in 
future  battles — perhaps  even  on  par  with  those  involved  in 
close  combat. 

In  sum,  the  current  RMA  encompasses  four  princi¬ 
ples — disengagement,  information  dominance,  synergy, 
and  civihanization.  As  will  be  shown  below,  the  Army  has 
begun  to  address  some  of  these  principles  through  the 
ATCCS  program. 

TOS,  TACFIRE  and  ARTADS:  The  First  Three 
Generations. 

It  has  always  been  assumed  that  there  are  certain  events  the 
commander  cannot  know  about  while  they  are  taking  place  on 
the  battlefield.  .  .  .  This  real-time  information  gap  has  been 
filled  by  intuition,  the  hunch,  seat-of-the-pants  brilliance,  the 
courage  to  make  critical  decisions  on  the  basis  of  incomplete 
information — and  luck.  This  has  been  as  true  in  Vietnam  as  it 
was  that  summer  [of  1914]  on  the  Marne.  But  as  the  Machine 
Age  has  given  way  to  the  Computer  Age,  a  quiet  revolution  has 
been  tEiking  shape  in  the  U.S.  Army,  one  that  promises  to  cut 
through  the  confusion  of  battle  in  a  fundamental  way.  It  comes 
under  the  rubric  of  ARTADS... and  presages  not  only  a 
revolution  in  technology,  but  in  methods  of  command,  military 
organization  and  human  attitudes.^® 

In  this  1972  article,  Ludvigsen  was  introducing 
ARTADS — for  Army  Tactical  Data  Systems — a  tactical 
command  and  control  system  to  automate  fire  support, 
coordinate  air  defenses,  ease  friendly  situational  aware- 
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ness,  and  standardize  reporting.  ARTADS  comprised  five 
systems,  at  various  stages  of  a  fragmented  development 
cycle:  the  Tactical  Operations  System  (TOS),  the  Tactical 
Fire  Direction  System  (TACFIRE),  the  air  defense 
command  and  control  system  (Missile  Minder),  the  Army 
Security  Agency’s  Control  and  Analysis  System  (CAS),  and 
the  combat  service  support  system  (CS^).^^  Established  as  a 
cohesive  program  in  April  1971,  ARTADS  was  the  Army’s 
third  generation  of  automated  C^  systems. 

The  first  generation  was  a  program  called  Fieldata,  a 
comprehensive  computer-communications  program  that 
envisioned  the  coupling  of  on-line  computers  and 
communications  systems  in  worldwide  networks.  Initial 
work  on  the  Fieldata  program  and  its  MOBIDIC  (Mobile 
Digital  Computer)  family  started  a  few  years  after  the 
conclusion  of  the  Korean  War.  Despite  rapid  progress,  the 
Army  canceled  Fieldata  during  its  1962  reorganization 
when  Fieldata’s  funding  was  eliminated.'^^  At  about  the 
same  time,  in  response  to  a  request  from  the  Pentagon,  the 
Command  and  General  Staff  College  (CGSC)  prepared  a 
comprehensive  plan,  called  ‘‘Command  Control  Information 
Systems  1970"  (CCIS-70),  to  integrate  automation  into  the 
battlefield.  The  CCIS-70  examined  five  battlefield 
functional  areas — maneuver,  intelligence,  fire  support,  air 
defense,  and  combat  service  support  (personnel  and 
logistics) — as  candidates  for  automation.  In  1964,  the  Army 
implemented  CCIS-70  as  the  Automatic  Data  Systems 
within  the  Army  in  the  Field  (ADSAF).  This  second 
generation  of  automated  C^  systems  envisioned  developing 
three  systems:  TACFIRE — for  fire  direction,  TOS— for 
maneuver  and  intelligence,  and  CS^ — for  combat  service 
support.^^  This  alignment  continued  in  the  third  generation 
(ARTADS),  but  in  ARTADS  the  most  important  systems 
became  TOS,  TACFIRE,  and  Missile  Minder.  Although 
ARTADS  is  beyond  the  scope  of  this  paper,  some  aspects  of 
TOS  and  TACFIRE  development  are  important  in  light  of 
the  later  ATCCS  systems. 
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TOS,  whose  development  started  in  the  mid-1960s,  was 
originally  conceived  to  standardize  reporting  upwards  and 
disseminate  five-paragraph  operations  orders  downwards. 
Maneuver  commanders  had  realized  that  the  reporting 
between  levels  of  command  was  too  slow.  As  the  keystone 
system  in  ARTADS,  TOS  was  to  be  interoperable  with 
TACFIRE  and  Missile  Minder.  The  initial  effort  was  the 
Seventh  Army  TOS  in  Europe.  After  little  success,  the  Army 
sought  to  apply  TOS  to  a  lower  level  of  command  and 
therefore  in  1975  brought  7A  TOS  to  Fort  Hood  to  become 
the  Division  Tactical  Operating  System  (DTOS,  or  TOS2).^^ 
At  this  point,  TOS2  and  TACFIRE  shared  a  common 
hardware  platform,  but  TOS2’s  software  for  intelligence 
and  maneuver  functions  did  not  perform  to  required 
standards.  Thus,  in  1978,  Congress  canceled  the  $100 
million  program."^^ 

In  1960,  the  Army  started  developing  TACFIRE,  to 
automate  the  process  of  field  artillery  support  to  maneuver 
forces.  In  1967,  the  Army  awarded  its  first  Total  Package 
Procurement  (TPP)  contract  to  Litton  Industries.  This 
contract  covered  development  as  well  as  all  subsequent 
production,  in  effect  ruling  out  any  future  competition  for 
TACFIRE’s  production.  The  original  TPP  contract  was  very 
ambitious,  spanning  a  mere  69  months,  with  the  first 
systems  to  be  delivered  to  the  Army  for  testing  after  22 
months.^^  Needless  to  say,  this  schedule  proved  too 
ambitious  and  slipped  tremendously.  In  his  TACFIRE  case 
study,  Salisbury  offers  three  major  causes  for  slippage. 

First,  the  TPP  contract  had  an  incentive  structure  which 
allowed  the  contractor  to  opt  for  improved  system 
performance  at  the  expense  of  increased  cost  and  a 
stretched  out  time  schedule — which  the  contractor  did,  as  it 
was  in  his  profit  interest  to  do  so.  Second,  in  1971  when 
TACFIRE  shifted  to  the  ARTADS  program  office  at  the 
Electronics  Command  at  Fort  Monmouth,  software 
development  remained  under  the  Computer  Systems 
Command  (CSC)  at  Ft.  Belvoir.  This  effectively  split  the 
program  between  two  major  commands,  as  CSC  was  not 
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part  of  the  Army  Materiel  Command.  This  division  in 
command  was  exacerbated  by  the  physical  distance 
between  software  and  hardware  development. 

Third,  and  most  importantly,  TACFIRE  contract 
management  was  supposed  to  be  maintained  through  a 
series  of  reviews;  no  intermediate  deliverable  items  were 
included  prior  to  the  actual  system  deliveries.  Then,  when 
Litton  finally  delivered  TACFIRE,  government  testing 
organizations  completed  formal,  methodical  and  intensive 
tests  based  on  the  AMC’s  published  Quahtative  Material 
Requirement  (QMR)  for  TACFIRE.  After  the  test  period,  the 
Army  returned  TACFIRE  to  Litton  to  correct  the  Testing 
and  Evaluation  Command’s  (TECOM)  list  of  deficiencies. 
This  process  of  sending  the  system  back  and  forth  between 
the  contractor  and  the  testing  community  caused  serious 
schedule  delays  and  frustrated  the  field  artillery  commu¬ 
nity,  which  had  been  expecting  the  system  since  1960. 

Finally,  in  August  1973 — about  the  time  when  the 
original  contract  had  planned  for  full-scale  production  to  be 
completed — the  Army  sent  out  a  formal  message 
designating  the  Field  Artillery  Center  as  “the  using  agency 
for  TACFIRE”  and  assigning  it  with  the  specific  task  of 
reviewing  all  TECOM  reports  to  “determine  from  the  user 
standpoint  the  minimum  acceptable  level  of  performance 
required  in  each  deficient  This  decision  was  a 

landmark  for  information  systems  development,  because  it 
drew  the  real  user  into  the  development  loop  for  the  first 
time. 

Before  this  time,  the  prevailing  method  for  designing 
software  was  “waterfall  development,”  in  which  the 
contractor  collected  all  of  the  requirements,  completed 
systems  design  once  and  delivered  a  final  product.  Because 
of  waterfall  development’s  ease  for  funding  and  design,  it 
was  preferred — and  arguably  still  is — by  the  develop¬ 
mental/testing  community,  contractors  and  Congress.  With 
TACFIRE,  waterfall  development  was  replaced  by  “spiral 
development,”  in  which  the  contractor  collects  some 
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requirements;  develops,  tests  and  fields  an  interim  product; 
and  uses  information  from  this  process  to  define 
requirements  further. 

Spiral  development — ^which  Salisbury  called  “Find,  Fix, 
and  Test” — ^‘'sought  to  collapse  [the  development-testing] 
cycle  into  much  shorter  intervals,  handling  fewer  problems 
at  a  time,  and,  with  the  aid  of  the  user  and  tester,  providing 
early  feedback  to  the  contractor  as  to  the  adequacy  of  his 
solutions. Despite  these  innovations  in  TACFIRE’s 
development  cycle,  when  it  was  finally  fielded  in  1980,  the 
testing  community  was  still  unsatisfied  with  the  final 
product,  and  the  Government  Accounting  Office  recom¬ 
mended  dela3dng  full-scale  production  until  more  hardware 
and  software  deficiencies  had  been  corrected. 

This  short  summary  of  TOS  and  TACFIRE  illuminates 
five  characteristics  which  were  to  become  a  pattern  in 
subsequent  Army  automation  development  and  acquisition. 
First,  as  Wilson  and  Heitzke  argue,  ARTADS  systems  were 
needed  for  two  reasons:  externally,  a  highly  mobile  enemy 
with  modern  weapons  increases  the  battle  tempo  and 
necessitates  a  rapid  reaction  capability,  and,  internally,  an 
overwhelming  supply  of  information  cannot  be  evaluated 
and  processed  manually  in  time  for  a  commander  to  make 
his  decisions.^®  Second,  the  Army  set  out  to  develop  and 
acquire  systems  for  which  a  mature  technological  capability 
did  not  yet  exist.  Thus,  these  grand  visions — which  were  not 
yet  technologically  feasible — were  exacerbated  by 
optimistic  testing  and  development  schedules.  Third,  the 
Army  imposed  a  rule  that  the  main  contractors  for 
TACFIRE  and  TOS  be  mainframe  manufacturers,  which 
points  to  a  bias  in  early  development  towards  hardware  and 
may  have  contributed  to  the  software  development  and 
hardware-software  integration  problems  which  plagued 
both  systems.^® 

Fourth,  this  misunderstanding  of  the  software  develop¬ 
ment  process  exacerbated  the  testing  procedure.  As 
Salisbury  noted. 
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the  testing  system  has  still  not  matured  in  its  understanding  or 
accommodation  of  software-based  systems.  A  “perfect”  software 
system  of  any  magnitude  with  zero  deficiencies  has  yet  to  be 
developed,  either  in  the  commercial  world  or  in  the  military . . . 
Management  decisions  must  be  based  on  enlightened  quali¬ 
tative  judgments  rather  than  a  simple  quantitative  tally  of 
deficiencies.®® 

As  a  result,  the  testing  process  was  more  attenuated  than  it 
needed  to  be,  which  created  great  tension  between  the 
testing  community  and  the  practitioners  in  the  field  who 
would  use  the  system.  While  TECOM  focused  on  having  a 
methodical,  intensive,  thorough,  and  cost-conscious 
acquisition  process  to  ensure  that  sll  stated  requirements 
were  met,  the  field  artillerymen  were  impatiently  waiting  to 
train  with  TACFIRE.  Salisbury  argued  that  the  solution  to 
the  problem  of  developing  highly  complex  systems  was 
Find,  Fix,  and  Test,  because  this  procedure  drew  end  users 
into  the  process  and  allowed  for  incremental  improvements. 

The  significance  of  the  designated  user  cannot  be  over¬ 
emphasized.  Here  for  the  first  time  was  a  single  focal  point 
within  the  Army  empowered  to  speak  with  virtually  final 
authority  on  modifications  to  TACFIRE. . . .  This  new  procedure 
allowed  the  designated  user  to  ask  not  “does  the  system  do  what 
the  QMR  says  it  must,”  but  instead  “is  the  performance  of  the 
system  adequate  to  fulfill  the  needs  of  the  field  artillery?”®^ 

I  argue  that  these  five  characteristics — ^the  need  to  develop 
a  rapid  reaction  capability  to  fight  a  mobile  enemy,  the 
tendency  to  envision  systems  which  were  not  yet 
technologically  feasible,  the  bias  in  early  development 
towards  hardware,  a  misunderstanding  of  the  software 
development  process,  and  the  resulting  tension  between  the 
developmental/testing  and  user  communities — ^were  never 
adequately  addressed  and  appear  again  in  the  development 
of  later  systems. 
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Sigma  Star:  The  Fourth  Generation. 

Facing  a  canceled  TOS  program  in  1978,  then  Brigadier 
General  Emmett  Paige  and  then  Colonel  Alan  Salisbury, 
newly  assigned  as  TOS  program  manager,  tried  to  salvage 
the  pieces  of  automation.  Paige — ^who  later  retired  as  a 
lieutenant  general  and  recently  served  as  the  Assistant 
Secretary  of  Defense  for  C^I — and  Salisbury  recycled  two 
TOS  micro-computer-based  components — the  Tactical 
Commander’s  Terminal  (TCT)  and  the  Tactical 
Commander’s  Station  (TCS) — to  create  the  Maneuver 
Control  System  (MCS  Sigma).  As  with  TOS  and  TACFIRE, 
MCS  Sigma  and  the  other  Sigma  Star  systems  faced  a 
continual  tug-of-war  between  different  Army  com¬ 
munities — the  users  and  the  testers — ^with  different  goals 
and  different  incentives.  On  the  one  hand,  the 
developmental/testing  communities — including  contrac¬ 
tors,  systems  engineers,  TECOM  and  AMC — were 
motivated  by  a  disciplined,  developmental  approach,  an 
interest  in  thoroughly  testing  the  systems,  and  a  desire  to 
use  resources  wisely.  On  the  other  hand,  the  user 
community — including  software  developers  and  the 
practitioners  in  the  field — wanted  access  to  the  new 
technology  now,  before  a  slow  development  and  testing  cycle 
and  technological  change  rendered  the  systems  obsolete. 

A  decade  after  ARTADS,  the  Army  still  sought  a  system 
that  could  provide  horizontal  integration  of  information  on 
the  battlefield  across  functional  areas  (BFAs).  The  Army 
articulated  the  horizontal  function  as  a  “force  level  control 
system”  to  provide  an  automated  presence  for  each  BFA  at 
each  command  level,  from  corps  to  brigade.  The  new  concept 
was  called  Sigma  Star:  “Sigma”  to  symbolize  integration,  as 
sigma  is  the  classical  mathematical  symbol  for  integration, 
and  “Star”  to  symbolize  the  five  BFAs  (maneuver, 
intelligence,  fire  support,  air  defense,  and  service  support). 
Each  point  of  the  star  would  eventually  have  its  own 
command  and  control  system;  at  that  time,  some  version  of 
automated  control  already  existed  for  each  BFA  except 
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combat  service  support.  Salisbury  noted  that  the  original 
briefing  slides  for  Sigma  Star  resembled  “Starship 
Enterprise  charts,”  because  they  depicted  stacked  stars,  one 
for  each  level  of  command,  within  a  three-dimensional 
space.^^  Like  TOS  in  ARTADS,  MCS  Sigma  was  supposed  to 
be  the  keystone  to  Sigma  Star,  Eventually  the  system’s 
designers  understood  that  they  needed  to  keep  the 
commander  in  the  center  of  the  system.  As  retired 
Lieutenant  General  Robert  Donohue  noted,  this  slight  shift 
in  the  project’s  ideological  underpinning  became  graph¬ 
ically  represented  on  briefing  slides  with  a  soldier  depicted 
in  the  middle  of  Sigma  Star.®^ 

The  organizational  and  operational  vision  behind  Sigma 
Star  was  especially  prompted  by  doctrinal  changes  that 
were  developing  at  TRADOC.  In  July  1977,  General  Bonn 
Starry — a  former  V  Corps  commander  in  Frankfurt — 
assumed  command  of  TRADOC.  Starry’s  command 
experience — especially  his  concern  about  the  Warsaw  Pact’s 
second  echelon  and  follow-on  forces — extended  TRADOC’s 
appreciation  of  its  doctrinal  tasks  into  wider  and  deeper 
dimensions. 

Given  the  situation  of  active  defense  against  a  major, 
armor-heavy  attack  by  the  Warsaw  Pact  forces,  Starry 
envisioned  the  corps’  response  in  terms  of  a  structured  Central 
Battle,  which  he  defined  as  that  part  of  the  battlefield  where  all 
elements  of  firepower  and  maneuver  come  together  to  cause  a 
decision.  ...Starry’s  corps  overview  in  the  Central  Battle,  his 
command  goal  to  describe  it  analytically  and  his  desire  for  a 
battlefield  technology  plan  set  this  goal  in  the  mold  of  a  major 
plan,  to  be  assembled  by  a  systems  approach.®^ 

Intelligence  indicated  that  the  Warsaw  Pact’s 
second-echelon  and  follow-on  forces  would  “line  up”  in 
somewhat  predictable  patterns,  to  exploit  the  first-echelon 
attack,  and  Starry  believed  that  these  follow-on  forces  could 
be  “target-serviced”  by  corps.^^  Therefore,  Starry  conceived 
of  the  “critical  tasks  of  the  Central  Battle”  as  target-serving, 
air  defense,  suppression-counterfire,  command-control- 
communications-electronic  warfare,  and  logistical  support. 
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These  concepts — ^which  imagined  a  deeper  battlefield  with  a 
requirement  for  near  real-time  synthesis  capability — 
were  published  as  part  of  the  Battlefield  Development  Plan 
and  distributed  throughout  the  Army  in  November  1978.^® 

In  March  1981,  Starry  formally  published  the  opera¬ 
tional  concept  for  AirLand  Battle  and  an  operational 
concept  for  Corps  86.  Romjue  elegantly  summarized  the 
message  of  these  March  1981  concepts  in  a  few  points.  (See 
Figures  1  and  2.) 

First,  deep  attack  was  not  a  luxury,  but  an  absolute  necessity 
in  order  to  win.  Second,  deep  attack  required  tight 
coordination  with  the  decisive  close-in  or  assault  battle,  and 
with  the  rear  battle  so  that  the  scarce  means  of  attack  would 
not  be  wasted  on  attractive  targets  whose  destruction  actually 
had  httle  impact  on  the  end  result.  .  .  .  Third,  the  concept 
required  an  alert  mental  grasp  of  the  potentialities  of  the  new 
Army  86  equipment  already  in  production  and  oncoming. 
Commanders  had  to  have  the  feel  of  its  greater  lethality  and 
range,  the  more  responsive  command  and  control  created  by  its 
automated  systems,  and  exactly  how  the  new  sensor  systems 
opened  up  new  means  to  find,  identify,  and  target  the  enemy 
deep  and  assess  the  results.  . . .  Deep  attack  was  necessitated 
by  the  nature  of  the  Soviet  operational  maneuver.  .  .  .  the 
oncoming  second  echelon  had  to  be  slowed,  disrupted,  broken 
up,  dispersed  or  destroyed  in  a  deep  battle,  (emphasis  added)®^ 


CSWS  (Corps  Support  Weapon  System) 
GLCM  (Ground-Launched  Cruise  Missilel^l 
MLRS  (Multiple  Launch  Rocket  System)^^^^P 
Pershing  N. 

Copperhead  ^ 


FASCAM 

(Family  of  Scatterable  Mines) 

XMlkid 


^  ^  ASAS  (All  Source  Analysis 

System  (Corps/Division)) 
RPV  (Remotely  Piloted  Vehicle) 

^  *  TACS  AT  (Tactical  Satellite) 

^  SOTAS 

(Stand-Off  Target  Aquisition  System) 
TACFIRE  (Tactical  Fire  Direction) 


Source;  TRADOC  Pam  525-5,  Airland  Battle  and  Corps  Operations  -  1986,  March  25, 1981,  p.  4. 


Figure  1.  A  Substantial  Step  Toward  Future 
Capabilities. 
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Source:  TRADOC  Pam  525-5,  AirLand Battle  and  Corps  Operations-1986,  March  25,  1981,  p.  6. 


Figure  2.  The  Second  Echelon  Threat. 

Above  all  else,  AirLand  Battle  stressed  the  importance  of 
continuous  planning  to  integrate  fire  support,  electronic 
warfare,  deception  and  intelligence  with  maneuver.  In 
other  words.  Central  Battle  needed  a  command  and  control 
system  that  would  electronically  link  the  five  BFAs — -just  as 
Sigma  Star  envisioned. 

The  Army  86  equipment  would  provide  such  capabihties 
in  the  future,  but  there  was  a  question  whether  existing 
equipment  could.  Starry’s  doctrinal  review  occurred  exactly 
when  many  Army  officers  were  reawakening  after  the 
“hollow  Army  years”  to  a  Soviet  threat  in  Europe.  At  the 
same  time,  the  new  technologies  that  had  been  promised 
since  General  Westmoreland’s  speech  in  1969  had  not  yet 
seen  the  field.  Starry’s  doctrinal  modifications  resonated 
with  most  practitioners  and  articulated  their  overriding 
concern:  the  smaller,  professional  Army  of  the  late  1970s 
could  not  successfully  defend  against  the  larger  Soviet  bloc 
threat  without  new  systems.  As  a  result,  the  Army  reahzed 
that  the  materiel  development  and  acquisition  cycle  would 
have  to  run  faster  than  before,  “with  accelerated  fielding  of 
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new  systems  running  concurrently  with  both  improvement 
programs  and  development  of  future  systems.  A  total 
systems  approach  had  to  prevail.”®® 

Back  at  the  MCS  Sigma  program  office — and  concurrent 
to  Starr/s  major  doctrinal  changes — ^Paige  was  attempting 
a  new  approach  to  fielding  technology  in  the  system’s  design 
and  development  phase.  After  Find,  Fix,  and  Test’s  success 
in  tACFIRE  development,  Paige  and  Salisbury  believed 
that  “evolutionary  fielding” — spiral  development — ^was  the 
answer.  The  Army  would  field  a  baseline  system — ^with  an 
absolute  minimum  of  new  functions — ^to  “real  users”  in 
tactical  units  rather  than  surrogate  users  in  Army  schools, 
as  had  previously  been  the  practice.  Then  the  real  users, 
with  Salisbur3r’s  team  alongside  them,  would  recommend 
improvements  based  on  practical  experience  with  the 
system.  In  response,  improvements  would  be  made 
systematically.  To  initiate  this  new  scheme,  in  1980  MCS 
Sigma  software  development  moved  to  the  Combined  Arms 
Center  Development  Activity  (CACDA)  at  Ft.  Leavenworth, 
effectively  locating  software  development  with  the  users.®® 
Cushman  hailed  the  MCS  Sigma  fielding  as  the  “Army’s 
first  success  story  in  the  use  of  evolutionary  development.”®® 
The  Armed  Forces  Communications-Electronics  Associa¬ 
tion  (AFCEA)  seconded  Cushman’s  conclusion  in  a  1981-82 
study  which  came  out  strongly  in  favor  of  evolutionary 
development  and  an  increase  in  real  users’  involvement  in 
the  process.®^ 

The  Army  fielded  the  prototype  MCS  Sigma  to  VII  Corps 
in  Europe,  which  eventually  tested  it  in  the  1980  and  1981 
Reforger  exercises.®^  Dubbed  the  “Lunar  Lander”  by  the 
troops,  the  prototype  MCS  was  the  “size  of  a  stove  with  the 
memory  of  today’s  laptops”  and  could  push  data  over  tactical 
communications  links  at  a  rate  of  1.2  baud.  But  as  retired 
Colonel  Michael  Graves — ^the  former  operations  officer  of 
the  signal  battalion  which  tested  the  system — noted,  none 
of  his  soldiers  fully  understood  its  capabilities,  and  so  the 
system  was  used  to  automate  other  existing  tasks  such  as 
serving  as  a  “smart  telephone.”  Nonetheless,  it  was  the  first 
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time  a  computer  was  used  in  a  tactical  operations  center 
(TOC),  and  the  first  time  that  data  was  sent  over  tactical 
communications  lines.  ‘We  didn’t  know  it  then,  but  it  really 
was  the  dawn  of  0^1,”  Graves  said.®^ 

Salisbury,  who  attended  the  Reforger  tests  of  MCS,  said 
the  process  was  very  productive,  because  it  “got  the  system 
in  the  hands  of  troops  as  soon  as  possible.”®^  MCS  message 
traffic  bettered  older  communications  channels  by  hours 
and  provided  “such  a  clear  command  and  control  advantage 
as  to  distort  the  overall  exercise.”®^  (The  computer-equipped 
team  won.)  Nevertheless,  the  testing  community  was 
unsatisfied  with  the  system’s  results  in  the  exercises, 
calling  them  “anecdotal  evidence.”  The  testing  community 
wanted  formal  testing  results,  because  Reforger  did  not 
provide  any  “quantitative  measurement  of  how  efficient  the 
system  is.” 

An  anecdote  from  Reforger  1981  is  illustrative.  Retired 
General  William  E.  Depuy,  who  was  observing  the  exercise 
as  a  consultant,  was  present  at  an  after  action  review  with 
field  commanders  and  representatives  of  the  testing 
community.  After  an  objection  from  a  tester  looking  for 
quantitative  results,  Depuy  turned  to  then-Major  General 
Fred  MaHaffey,  the  3rd  Infantry  Division  commander  who 
had  used  MCS  during  the  exercise.  Depuy  asked  MaHaffey 
how  many  counterattacks  his  division  had  successfully 
launched  during  this  Reforger  with  MCS.  MaHaffey 
answered  20.  Depuy  then  asked  MaHaffey  how  many 
counterattacks  his  division  could  usually  launch  without 
MCS.  MaHaffey  answered,  “only  seven  to  ten.”  Depuy 
nodded  and  said,  “That  sounds  like  a  minimum  of  a  two  to 
one  improvement  with  MCS.”  Turning  to  the  tester,  he 
noted  pointedly,  “You  want  quantification,  you  got  it.” 
According  to  Salisbury,  the  Army  made  its  decision  to 
produce  MCS  partly  as  a  result  of  this  conversation.®^ 

Meanwhile,  field  commands  throughout  the  Army  were 
busy  with  their  own  “front-end  evolution.”  Tired  of  waiting 
for  the  Army  Materiel  Command  (AMC)  to  eventually 
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deliver  the  fancy  systems  they  were  promising — and 
spurred  on  by  Stands  doctrinal  revisions  and  the  renewed 
focus  on  the  Soviet  threat — commanders  started 
purchasing  off-the-shelf  commercial  gear  and  adapting  it  in 
their  own  commands  to  their  operational  uses.  Three 
commands  stand  out  as  examples.  First,  the  Communica¬ 
tions  Electronic  Command  (CECOM)  sponsored  the 
division-level  Distributed  Command  and  Control  System 
(DCCS),  which  used  off-the-shelf  technology  to  create 
databases  of  tactical  information.  DCCS  was  fielded  to  the 
High  Technology  Test  Bed  9th  Infantry  Division®^ — an 
experimental  hght  division  developed  to  counter  a  possible 
Middle  East  threat — which  tested  it  in  iterated  field 
exercises  through  1985.®®  Second,  the  18th  Airborne  Corps 
created  a  Tactical  Information  Control  System  comprised  of 
20  Apple-II  workstations  under  the  control  of  the  corps 
operations  officer  (G3).  These  computers  automated  corps- 
level  logistics,  command  and  control,  and  even  had  links 
into  the  worldwide  ARPA  net.  Perhaps  most  importantly. 
Forces  Command  used  “training  funds”  to  adapt  the  Apple 
II  computer  into  a  system  called  Microfix  to  aid  division  and 
corps  G2  sections.  By  the  end  of  1984,  Microfix  had  been 
assigned  an  Army  stock  number,  its  repair  parts  appeared 
in  the  supply  system,  and  a  substantial  number  of  them 
were  being  used  in  field  commands.®® 

This  mushrooming  of  front-end  initiatives  led  to  the 
formation  of  the  Army  C^  Initiatives  Program  (TACIP)  at 
the  Combined  Arms  Center  (CAC)  at  Ft.  Leavenworth. 
TACIP  established  procedures  for  tracking  field 
commanders’  initiatives,  identifying  and  funding  the  most 
promising  projects  and  terminating  those  which  lacked 
promise.  By  placing  TACIP  under  CAC — the  nominal  voice 
of  the  practitioner  community — ^the  Army  was  sending  a 
message.  Just  as  moving  MCS  software  development  to 
CACDA  located  it  with  its  users,  creating  TACIP  under 
CAC  circumvented  AMC’s  centralized  acquisition  bureauc¬ 
racy  and  encouraged  practitioners  in  the  field  to  experiment 
and  innovate. 
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In  1984,  the  Army  Training  and  Doctrine  Command 
(TRADOC)  and  AMC  wrote  a  joint  pamphlet  called 
“Non-Development  Item  (NDI)  Acquisition”  to  standardize 
an  Army-wide  process  for  rapidly  acquiring  or  adapting 
commercial  off-the-shelf  equipment  without  a  lengthy  R&D 
cycle.  The  preface  to  this  pamphlet  read  in  part: 

Greater  reliance  on  NDI  types  of  acquisition  is  the  wave  of  the 
future.  No  longer  can  we  continue  to  use  the  traditional 
heel-to-toe  development  life  cycle  management  approach  to 
satisfy  most  of  our  materiel  requirements.  It  takes  too  long  and 
time  is  money. . . .  Certain  technologies  are  advancing  so  rapidly 
that  we  can  find  ourselves  fielding  equipment  several 
technological  generations  behind  what  is  currently  available.™ 

With  this  pamphlet,  the  Army  in  effect  was  creating 
doctrine  for  procedures  that  had  already  become  adopted 
throughout  the  organization.  In  the  process,  the  Army  also 
consciously  abandoned  its  15-year-old  project  called  the 
Mihtary  Computer  Family  (MCF),  a  standard  automation 
platform  for  multiple  tasks  being  developed  by  General 
Electric,  RCA,  and  Raytheon.  This  concept  of  NDI 
off-the-shelf  computer  adaptation  to  meet  battlefield  needs 
caused  a  stir  in  the  defense  industry.  As  one  contemporary 
observer  noted,  “The  onslaught  of  contractors  trying  to  grab 
contracts  for  their  own  particular  NDI  computers  for 
tactical  use  rivals  the  Oklahoma  land  rush.”^^  Perhaps  most 
importantly,  the  advent  of  doctrinal  NDI  acquisition  forced 
the  Army  to  abandon  its  goal  of  system  interoperability. 
Each  contractor  tailored  its  product  to  a  different  sub-set  of 
the  automating  Army  community,  with  httle  regard  for  the 
ability  to  communicate  among  them.  As  Cushman  warned 
in  a  critique  of  the  Army's  automation  protocols  that  had 
developed  by  1985: 

The  protocol  is  detailed,  binding  and  implacable.  If  it  is  not 
right,  you  simply  do  not  pass  information  digitally.  .  .  . 
Interestingly,  when  the  different  communities  who  purport  to 
represent  the  artillerymen  .  .  .  and  the  logisticians,  and  the 
intelligence  experts,  and  the  air  defenders  .  .  .  and  the 
commanders  and  the  operations  officers  and  all  the  rest  began 
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to  develop  protocols  for  sharing  information  within  their 
various  spheres,  each  community  developed  a  different 
protocol.  Hard  to  believe,  but  true.  .  .  .  The  fundamental 
challenge  of  the  technical  community  in  modem  times  is  to 
arrange  the  protocols  so  that  these  communities  who  share  the 
conduct  of  theater  warfare  can  communicate  easily  with  one 
another  in  a  world  of  digital  information  flow.*^^ 

Hence  a  paradox:  although  Sigma  Star  intellectually 
envisioned  an  integrated  command  and  control  system 
which  would  allow  the  five  BFAs  to  communicate,  the 
organization — ^because  of  the  imperatives  of  organizational 
politics — ^pursued  a  course  of  action  antithetical  to  this  goal. 

In  sum,  MCS  Sigma  and  Sigma  Star  embodied  many  of 
the  characteristics  of  earlier  automated  development 
acquisitions.  First,  just  as  ARTADS  was  conceived  to 
provide  rapid  reaction  capability  to  fight  a  mobile  enemy. 
Sigma  Star  was  designed  for  a  similar  purpose.  Its 
developers  hoped,  in  Clauswitzian  terms,  to  minimize  the 
“fog  of  war” — or  in  the  language  of  the  current  RMA,  to 
maximize  the  friendly  OODA  cycle.  They  also  tailored  the 
system  to  counter  the  largest  perceived  threat,  Warsaw 
Pact  armed  forces  streaming  across  the  Fulda  Gap.  With 
these  two  ideas,  much  of  the  intellectual  innovation  of  later 
Army  automation  plans — adapted  from  ARTADS — ^was 
already  incorporated  in  the  Sigma  Star  concept. 

Second,  the  evolutionary  (“spiral”)  development  concept 
used  with  MCS  Sigma  exacerbated  an  already-tense 
relationship  between  the  user  and  tester  communities.  As 
with  ARTADS,  the  testers  were  motivated  by  a  disciplined, 
developmental  approach,  an  interest  in  thoroughly  testing 
the  systems,  and  a  desire  to  use  resources  wisely.  In 
contrast,  the  user  community — ^reawakening  to  the  Soviet 
threat  being  articulated  by  General  Starry  at  TRADOC — 
wanted  access  to  the  new  technology  now.  Senior  Army 
leadership  tacitly  approved  of  and  encouraged  these  user- 
level  initiatives  by  creating  TACIP  at  Ft.  Leavenworth. 
Suddenly,  the  entire  service  wanted  to  overthrow  the 
deliberate,  bureaucratic  acquisition  process,  to  ensure  that 
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systems  were  not  already  technologically  obsolete  when 
they  reached  soldiers.  In  other  words,  because  centralized 
development  under  AMC  had  not  worked,  the  Army 
decentralized  activity  to  move  development  “forward,” 
albeit  imperfectly. 

Yet  this  mushrooming  of  front-end  initiatives  had  a  cost 
as  well.  As  with  the  earlier  ARTADS  and  subsequent 
ATCCS  systems.  Sigma  Star  automation  efforts  had 
problems  with  intra-  and  inter-service  interoperability  and 
redundancy.  Earlier  systems  had  problems  communicating 
with  those  of  other  services,  but  by  the  mid-1980s,  the  NDI 
acquisition  strategy  caused  interoperability  problems 
within  the  Army  itself.  Advances  in  technology  had 
outpaced  the  lengthy  acquisition  cycle  and  caused  a 
proliferation  of  temporary  and  incompatible  systems 
throughout  the  Army.  By  the  mid-1980s,  these  innovative 
efforts  within  various  commands  began  to  appear  rash  and 
improvised.  As  Cushman  noted  in  1985,  Army  theater-level 

systems  “neither  exploit  the  present  capabilities  of 
technology  nor  does  the  system  for  their  development 
adequately  provide  that  future  systems  will.”^^  A  backlash 
towards  deliberate,  disciplined,  interoperable  systems — ^the 
developmental  and  testing  communities’  domain — was 
beginning. 

ATCCS. 

ATCCS  built  upon  the  legacy  of  Sigma  Star,  which 
established  a  pattern  of  automation  development  and 
acqmsition  begun  before  the  Vietnam  War  and  laid  the 
foundations  for  two  later  trends.  First,  most  of  ATCCS’ 
intellectual  conceptualization  came  from  the  Sigma  Star 
period.  I  argue  that  until  the  next  major  organizational 
upheaval  at  the  end  of  the  Cold  War,  there  was  very  little 
intellectual  or  innovative  content  added.  Second,  the 
tension  between  the  users  and  testers  continued  in  this 
period,  with  the  developmental/testing  communities  having 
a  larger  influence  than  in  the  late  1970s  and  early  1980s. 
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Thus,  a  dichotomy  between  ATCCS  as  a  concept  and  ATCCS 
in  reality  continued  until  DESERT  STORM.  To  simplify  the 
discussion,  these  two  trends  will  be  discussed  in  turn. 

As  a  concept,  ATCCS  added  little  intellectual  or 
organizational  value  to  the  Sigma  Star  idea.  In  May  1986, 
the  name  ATCCS  replaced  Sigma  Star,  but  the  program 
remained  essentially  the  same:  the  five  BFAs  were  each  to 
develop  a  C^  system  which  could  communicate  with  the 
other  BFAs  horizontally  and  vertically.  Although  the  Sigma 
Star  concept  had  envisioned  horizontal  integration,  the  NDI 
acquisition  plan  had  made  that  kind  of  coordination  and 
interoperability  almost  impossible.  Instead,  each  BFA  had 
begun  to  develop  its  own  system,  with  its  own  program 
office,  its  own  defense  contractors,  and  its  own  protocols.  In 
effect,  the  BFAs  were  only  connected  by  a  star  on  the 
briefing  slides.  The  ATCCS  program  was  still  under  the 
Combined  Arms  Combat  Development  Activity  (CACDA) — 
where  it  had  moved  during  Paige’s  evolutionary  develop¬ 
ment  plan  and  Starry’s  Corps  86  concept.  Therefore,  the 
new  program  manager,  then  Colonel — now  retired  Major 
General — Gerry  Granrude,  tried  to  refocus  on  horizontal 
integration  to  solve  the  developing  problem  of  “stovepipes”: 

Stovepipes — communications  from  subordinate  to  superior — 
are  inevitable  in  large  bureaucratic  organizations.  .  .  . 
stovepipes  are  often  a  deceptively  efficient  way  to  operate.  As  a 
general  proposition,  significant  economies  of  scale  or 
synergistic  new  capabilities  can  be  created  by  forcing 
horizontal  coordination  where  it  has  not  previously  existed.  It 
forces  bright,  capable  people  to  look  at  problems  from  new 
perspectives.’^ 

Like  Sigma  Star,  the  five  ATCCS  systems  were  to 
communicate  using  the  standard  U.S.  Message  Text 
Format  (USMTF),  which  would  allow  them  to  generate, 
send,  and  receive  messages  automatically.^®  With  such 
integration,  ATCCS  was  supposed  to  become  the  “system  of 
systems.”^®  Retired  Colonel  Mitch  Mitchell,  who  served  as 
the  program  manager  for  ATCCS  common  hardware  and 
software,  defined  the  goal  of  ATCCS  as: 
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...  to  get  all  the  BOSs  [battlefield  operating  systems]  to 
communicate  so  that  we  could  be  more  responsive  to  the  enemy 
threat.  We  were  trying  to  lift  the  fog  of  war  and  to  get  within  the 
thinking  radius  of  the  enemy. ...  If  you  can  see  him  and  make 
decisions  before  he  does,  you  can  lift  your  fog  of  war. 

In  short,  ATCCS  was  new  packaging  for  an  idea  which  had 
been  fully  developed  for  a  decade. 

At  the  level  of  development  and  acquisition,  ATCCS  was 
having  mixed  results.  As  mentioned  above,  by  the  time  that 
ATCCS  was  ‘‘created,”  each  BFA  had  developed  a 
stovepiped  system.  Ford  Aerospace  (later  Loral),  Singer’s 
Librascope  Division,  and  TRW  developed  MCS.  Magnovox, 
having  beaten  out  a  lighter  system  developed  by  Litton, 
built  the  Advanced  Field  Artillery  Tactical  Data  System 
(AFATDS),  TACFIRE’s  successor.  Multiple  contractors, 
including  the  Jet  Propulsion  Laboratory  in  Pasadena  and 
Norden’s  Digital  Equipment  Corporation,  were  building  the 
intelligence  system,  called  the  All  Source  Analysis  System 
(ASAS).  Loral  used  its  Rolm  Hawk  computers  to  develop  the 
Forward  Area  Air  Defense  C^I  System  (FAAD  C^I),  Missile 
Minder’s  successor.  The  automated  system  for  combat 
service  support  was  being  developed  under  two  names  by 
two  contractors:  Burroughs  was  building  the  Tactical 
Combat  Service  Support  System  (TACSS),  while  General 
Electric  was  developing  the  Direct  Army  Support  System 
(DASS).'^^ 

To  hasten  the  integration  of  the  five  BFAs,  in  May  1987 
the  Army  announced  that  all  ATCCS  computers  would  be 
required  to  operate  on  a  common  hardware  and  software 
development  platform.  The  Army  chose  AT&T’s  UNIX-5 
operating  system  to  serve  as  the  basis  of  the  common 
software  applications.  Miltope,  to  the  surprise  of  many 
watching  the  defense  industry,  won  the  contract  for  the 
common  hardware  and  software  in  August  1988.^®  The 
Army  decided  that  MCS,  AFATDS,  FAAD,  and  the  two 
combat  service  support  systems  would  transition  to 
Miltope’s  common  hardware  and  software.  In  the  process. 
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new  contractors  bid  for,  and  in  some  cases  won,  the  right  to 
build  the  new  common  systems.  Only  ASAS,  the  intelhgence 
system,  was  not  required  to  transition  to  the  common 
hardware-software — perhaps  because  the  Army  intelli¬ 
gence  community  understood  its  future  lay  in  automation 
and  thus  was  more  proactive  about  its  respective  ATCCS 
system’s  development  than  any  other  BFA.®®  As  Retired 
Colonel  Dominick  Basil,  a  former  Deputy  Commander  at 
CECOM  and  former  project  manager  of  the  SINCGARS 
radio  system,  noted:  ‘ASAS  worked  well  because  its  domain 
experts  wanted  it  to  work  and  needed  it  to  work.”®^  Even 
today,  ASAS  has  not  yet  moved  to  the  common  hardware 
and  software;  this  switch  will  finally  take  place  when  the 
Army  fields  ASAS  Block  II  in  1998— more  than  a  decade 
after  the  Army  levied  the  original  requirement.®^ 

Despite  their  separate  development  histories,  the  five 
systems  shared  common  development  problems.  As  with 
TOS  and  TACFIRE  before  them,  the  biggest  stumbling 
block,  according  to  Mitchell,  was  in  the  development  of  each 
BFAs  application  software  (especially  for  MCS).  A  vicious 
cycle — ^referred  to  as  “requirements  creep” — ensued  in 
which  the  civilian  contractors  would  develop  software,  the 
Army  customers  would  change  their  stated  requirements, 
and  then  the  contractors  would  need  to  modify  develop¬ 
ment.  “We  in  the  mihtary  have  a  tendency  to  constantly 
change  requirements,  which  is  hard  for  the  civilian 
contractors  to  accommodate. ...  At  some  point,  the  military 
needed  to  basehne  its  requirements  and  run  with  it.”®®  This 
was  complicated  by  systems  flunking  operational  tests,  yet 
being  developed  further  before  meeting  the  standards.  For 
example,  a  review  of  AFATDS  in  August  1987  showed  that 
the  system’s  timeline  had  slipped  2  years  to  1993  fielding 
because  of  Magnavox’s  poor  performEince.  By  April  1988, 
Magnavox  was  spending  about  $1  million  per  month  of  its 
own  funds  to  try  to  repair  the  project.®'^  Such  blunders  not 
only  caused  the  ATCCS  programs  to  rotate  leaders  often, 
but  they  also  lay  at  the  heart  of  a  handful  of  decisions  by 
Congress  to  delay,  suspend,  or  delete  ATCCS  funding.®®  By 
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October  1990,  the  Senate  froze  all  spending  on  ATCCS 
development,  because  the  five  BFAs  had  not  yet  complied 
with  the  1987  plan  to  transition  to  Miltope’s  common 
ATCCS  system.®^ 

This  acquisition  nightmare  led  to  the  wasteful  pxirchase 
of  extra  hardware  and  peripherals,  which  were  frequently 
rendered  obsolete  by  the  time  the  software  had  been 
debugged.  As  Mitchell  succinctly  stated  the  problem:  “You 
can’t  buy  the  boxes  until  you  have  correctly  developed  the 
software.”^^  These  misspent  funds  contributed  to  a  spate  of 
scathing  studies  from  the  Government  Accounting  Office 
(GAO).  Some  of  their  findings  included: 

1.  Unable  to  develop  its  full  complex  ASAS  computer,  the 
Army  opted  to  build  an  interim  system  meeting  minimal 
capabilities  for  the  European  theater  against  the  potential 
Soviet  threat.  GAO  charged  that  the  interim  system,  called 
Warrior,  could  not  even  meet  the  bare  minimum  require¬ 
ments.®®  In  another  study,  GAO  found  that  the  intelligence 
community  at  Ft.  Huachuca  was  building  a  third  system — 
called  Hawkeye — ^because  they  did  not  like  the  buMness  of 
the  original  ASAS  system.  These  three  versions  of  the  same 
system  were  not  interoperable.®® 

2.  Both  ASAS  and  CSSCS  were  advancing  to  production 
stage  while  their  systems  were  still  failing  tests.  Both 
systems  were  advanced  after  failing  the  minimum 
requirements  for  connectivity  with  other  ATCCS  systems. 
The  ASAS  collateral  enclave — ^the  only  portion  which 
operates  at  the  common  ATCCS  security  classification 
level — was  never  even  used  in  the  tests.®® 

3.  When  MCS  was  tested  in  early  1990,  the  Army 
Operational  Test  and  Evaluation  Command  found  that  the 
system  “has  not  demonstrated  its  effectiveness  in  providing 
timely,  accurate,  and  useful  information  in  a  battlefield 
environment.”  In  addition,  GAO  noted  commanders  who 
had  used  MCS  indicated  that  it  “provides  little  to  no  aid  in 
controlling  maneuver  forces.”®^  GAO  claimed  that  the 
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initial  deplo3mient  of  MCS  computers  had  been  used  mostly 
as  only  a  very  expensive  way  to  relay  facsimile  messages.®^ 

4.  After  years  of  developing  a  rugged  PC-based  Common 
Hardware  standard  computer,  the  Army  needed  much  more 
capacity  and  accepted  bids  for  a  Command  Hardware 
(CH)-2  program.  GAO  charged  that  the  Army  had  failed  to 
justify  the  costs  or  prepare  an  adequate  test  of  CH-2.  GAO 
also  criticized  the  Army  for  planning  to  field  CH-2  only  to 
heavy  divisions,  which  could  skew  its  design.  Without 
fielding  CH-2  to  all  types  of  divisions  on  all  five  ATCCS 
systems,  the  Army  was  in  effect  forfeiting  its  original  goal  of 
a  standard  battlefield  computer  and  software.^^ 

As  an  audit  agency,  GAO’s  natural  proclivity  is  to 
overstate  problems.  Nonetheless,  ATCCS  acquisition  and 
development  was  not  successful  during  this  period. 

In  sum.  Army  automation  during  the  late  1980s 
remained  paralyzed  by  the  tension  between  the  testing  and 
user  communities  that  had  existed  since  TOS  and 
TACFIRE.  As  the  previous  section  explained,  there  was  a 
widespread  view  by  1985  that  the  user  community’s  free 
reign  over  technology  acquisition  had  gotten  out  of  control. 
As  a  result,  for  the  rest  of  the  1980s,  there  was  steady 
movement  to  rein  in  the  users  who  had  encouraged  the 
reckless  development  of  stovepipes.  From  the  Army^s  1987 
decision  to  establish  a  common  ATCCS  hardware  and 
software  to  the  scathing  GAO  studies  about  fiscal  abuses 
and  testing  failures,  ATCCS  development  during  this 
period  steadily  returned  to  the  developmental  and  testing 
communities’  domains.  The  cost  of  this  deliberate 
development  and  acquisition,  however,  was  that  technology 
continued  to  outpace  ATCCS.  For  the  first  time,  the 
commercial  sector  replaced  DoD  on  the  cutting  edge  in 
information  technology — a  fact  which  DoD  refused  to 
recognize  and  counterproductively  fought  for  some  time.  As 
the  next  section  will  argue,  the  Army  did  not  wake  up  to 
these  shortcomings  until  the  twin  milestones  of  the  early 
1990s — ^DESERT  STORM  and  the  end  of  the  Cold  War. 
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After  the  Cold  War:  ATCCS  in  the  Army  Battle 
Command  System. 

By  the  time  the  Army  was  preparing  for  Operation 
DESERT  STORM,  the  ATCCS  program  was  mired  in 
bureaucratic  paralysis.  Of  the  five  BFA  control  systems, 
only  MCS  had  been  fidded  to  regular  units;  the  four  other 
systems  still  remained  in  their  development  and  testing 
cycles.  And  in  a  move  surprisingly  similar  to  the  Microfix 
acquisition  during  the  NDI  era,  the  intelligence  community 
had  adapted  and  fielded  Warrior — a  stop-gap  system  used 
in  the  European  Central  Region  and  taken  to  the  Persian 
Gulf.  As  in  previous  periods  of  Army  automation,  two 
themes  continued  to  characterize  ATCCS  after  the  Cold 
War.  First,  despite  the  major  geopolitical  changes  of  the 
post-Cold  War  era,  ATCCS’  concept  was  fundamentally 
identical  to  the  old  Sigma  Star  vision.  Second,  the  perpetual 
tug-of-war  between  the  developmental/testing  and  user 
communities  continued  to  hamper  ATCCS’  development 
and  acquisition  process.  What  did  change,  however,  was  the 
balance  between  the  two  communities.  As  in  the  late  1970s, 
when  the  Army  reawakened  to  a  large  Soviet  threat  and 
General  Starry  articulated  a  real  need  for  technological 
improvements,  the  end  of  the  Cold  War  tipped  the  scale 
back  in  the  user  communit^s  favor.  Just  as  senior  Army 
leadership  created  TACIP  in  the  early  1980s  to  place 
innovation  authority  and  resources  with  CAC  and  the  user 
community,  senior  Army  leaders  in  the  early  1990s  followed 
similar  tactics.  Once  again,  as  the  pendulum  swung  away 
from  the  methodical,  disciplined  development  of  systems 
engineers  to  field  officers  chafing  on  their 
technologically-outdated  systems,  the  user  community 
gained  control.  This  section  outlines  the  “revolution”  which 
culminated  with  Force  XXI. 

DESERT  STORM  has  been  hailed  as  the  first  example  of 
“Third  Wave”  warfare,  a  preview  of  war  in  the  Information 
Age.  Yet  it  is  equally  possible  to  categorize  the  conflict  as  the 
last  “Second  Wave”  war,  as  van  Creveld  does: 
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In  Operation  DESERT  STORM,  units  moved  hundreds  of 
kilometers  in  a  matter  of  days.  This  compares  well  with  Soviet 
operations  in  the  latter  part  of  World  War  II  and  in  Manchuria 
in  1945.  DESERT  STORM,  however,  was  more  movement 
than  maneuver,  in  part  because  the  Iraqis  themselves  proved 
so  passive.  Given  their  passivity,  tempo — the  notion  of 
entering  into  the  enemy’s  observation-orientation-decision- 
action  (OODA)  cycle — never  came  into  play.  Tempo  embodies 
the  concept  of  acting  before  the  other  can  react.  The  concept 
does  not  have  much  meaning  if  the  other  hardly  reacts  at  all.®^ 

Van  Creveld  argues  that  the  Army  would  not  have  been  able 
to  exercise  tempo  had  the  opponent  been  more  active, 
because  it  seemed  “more  interested  in  synchronizing  the 
moves  of  its  own  components  than  in  vigorously  exploiting 
battlefield  success  by  sending  spearheads  forward.”^® 

One  reason  for  this  criticism  might  have  been  the 
proliferation  of  stovepiped  systems  during  the  1980s — a 
different  contractor  with  a  different  system  for  each 
different  sub-community.  DESERT  STORM  demonstrated 
intense  problems  with  inter-  and  intra-service  connectivity 
and  interoperability.  This  lack  of  connectivity  was  a 
contributing  factor  to  the  fratricide  of  friendly  troops,  which 
sparked  bad  publicity  for  the  military.  In  short,  the 
American  people  would  not  tolerate  friendly  fire  losses  from 
arguably  the  most  technologically  advanced  armed  force  in 
the  world.  The  military — and  especially  the  ground 
forces — ^needed  to  fix  this  problem.  That  the  U.S.  military 
had  problems  with  “situational  awareness”  and 
interoperability  in  the  Persian  Gulf  was  even  more 
apparent  in  comparison  to  the  much  less  technologically 
advanced  Iraqi  military.  The  question  arose:  if  the  U.S. 
Army  has  such  a  technological  advantage,  why  isn’t  the 
technology  being  used  to  minimize  the  fog  of  war? 

In  the  course  of  Operation  DESERT  STORM,  the  Army  saw 
smart  weapon  technology  overpower  opponents  in  terms  of 
time,  distance  and  mass,  but  noted  deficiencies  in  the 
command  and  control  of  these  weapons,  particularly  for  the 
lowest  echelons.  The  lowest  command  levels  were  not 
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situationally  aware  of  all  of  the  activity  in  their  immediate  area 
of  interest.  The  Army  needed  improvement  in  combat 
identification,  fratricide  prevention  and  information  sharing 
between  ground  and  air  weapons  platforms  to  enable 
commEinders  to  conduct  both  close  and  deep  combat.^ 

Among  the  'lessons  learned”  from  DESERT  STORM,  this 
was  perhaps  the  most  important.  As  General  J ohn  H.  Tilelli, 
Jr. — a  former  division  commander  in  DESERT  STORM  and 
then  the  Deputy  Chief  of  Staff  for  Operations  and  Plans 
(DCSOPS) — testified  before  Congress  in  1994,  “a  key 
problem  in  the  desert — combat  identification  and 
situational  awareness”  could  only  be  solved  “by  precisely 
locating  everyone  on  the  battlefield.”  This  admission  to 
Congress  stood  out  from  the  rest  of  Tilelli’s  testimony,  which 
was  relatively  complacent  and  status  quo:  the  Gulf  War  had 
validated  AirLand  Battle  doctrine.  Army  training 
strategies  at  NTC  and  other  training  centers,  and  the  “Big 
Five”  weapons  systems — ^the  Abrams  tank,  the  Bradley 
Infantry  Fighting  Vehicle,  Patriot  missiles,  multiple  rocket 
launchers  and  the  Apache  attack  helicopter.  Perhaps 
doctrine  needed  a  slight  tweak  for  the  joint  environment, 
and  perhaps  strategic  mobility  capability  could  use  some 
improvement,®^  but  on  balance,  the  Army  was  well  perched 
for  the  next  war — as  long  as  the  battlefield  looked  roughly 
the  same. 

The  Army’s  poor  performance  with  “situational 
awareness”  during  DESERT  STORM  set  the  stage  for 
organizational  change  and  information  technology 
innovation.  However,  it  was  the  convergence  of  the 
DESERT  STORM  “lessons  learned”  with  two' other  factors 
that  caused  Force  XXI.  The  first  was  a  geopolitical  change  in 
the  international  balance  of  power.  The  end  of  the  Cold  War 
effectively  shattered  the  Warsaw  Pact  threat  towards  which 
AirLand  Battle  and  the  Army  86  modernization  had  been 
geared.  Second,  a  group  of  senior  Army  leaders  awakened  to 
the  decreased  international  threat  and  saw  the  writing  on 
the  wall.  In  an  era  of  decreased  threat  and  shrinking 
defense  budgets,  any  military  service  without  a  revised 
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mission  would  lose  to  the  other  services.  As  under  Starry, 
the  Army  needed  a  makeover  to  fight  a  new  threat — except 
this  time  the  threat  was  force  reductions,  not  the  Soviet  Red 
Hordes.  The  two  senior  leaders  most  responsible  for  this 
face-lift  were  General  Gordon  Sullivan,  then  Chief  of  Staff  of 
the  Army,  and  General  Frederick  Franks,  the  TRADOC 
commander. 

This  synergism  between  the  Gulf  War  experiences,  the 
end  of  the  Cold  War,  and  new  senior  Army  leadership 
created  the  right  conditions  for  broad  change.  Sullivan  and 
Franks  claimed  to  be  making  an  enormous  change  in  the 
Army’s  organization  and  use  of  technology,  but  I  argue  that 
their  statements  may  have  been  exaggerated.  The  story  of 
ATCCS  and  battlefield  C^  is  merely  a  part  of  the  broader 
Force  XXI  vision;  nonetheless,  the  course  which  ATCCS 
takes  afber  the  Cold  War  is  fairly  emblematic  of  the  current 
RMA  overall. 

As  General  Starry  was  to  AirLand  Battle  and  Sigma 
Star,  so  General  Sullivan  was  to  information  technology  on 
the  battlefield.  As  retired  Colonel  Dominick  Basil  said, 
‘Without  General  Sullivan,  it  would  have  never  happened. 
He  was  a  zealot”;  recasting  the  ATCCS  project  “matched  his 
vision.”®®  In  December  1991,  Sullivan  created  the  Army 
Digitization  Task  Force  to  study  the  Army’s  use  of 
information  technology.  The  ADTF  report  recommended  a 
substantial  overhaul  of  the  Arm^s  current  C^  architecture 
and  a  renewed  focus  on  battlefield  digitization.  Sullivan, 
who  was  heavily  influenced  by  the  Tofflers  and  other 
information  warfare  theorists,  was  receptive  to  these  ideas. 
By  the  spring  of 1992,  when  Basil — ^then  deputy  commander 
of  CECOM — ^brought  Sullivan  a  video  conceptualizing  digi¬ 
tization  and  situational  awareness,  Sullivan  was  won  over. 
‘We  left  the  video  on  a  Friday  afternoon  and  he  called  me  at 
home  that  night  at  2200,  completely  ecstatic.  “That  is 
exactly  what  I  need  for  the  Army,’  he  said.”  The  33-minute 
video  advocated  two  concepts:  horizontally  integrating 
existing  C^  systems  and  extending  automation  to  the  lowest 
echelons  of  the  battlefield  via  a  tactical  internet.®®  Although 


36 


the  first  idea  was  hardly  new,  both  concepts  become  the 
foundation  of  Sullivan’s  Force  XXI. 

At  a  broad  level,  Sullivan’s  vision  accomplished  two 
things.  First,  he  provided  the  Army  with  the  intellectual 
paradigm  for  redefining  itself  in  the  post-Cold  War  world. 
Without  a  Soviet  threat  to  motivate  funding  for  training  and 
weapons  procurement,  Sullivan  shifted  the  Army  towards  a 
new  mission — ^force  projection,  “the  demonstrated  ability  to 
rapidly  alert,  deploy  and  conduct  operations  anywhere  in 
the  world.”^®®  By  1993,  he  succinctly  captured  this  new 
mission  in  five  bullets:  project  and  sustain  combat  power, 
protect  the  force,  win  the  information  war,  dehver  precision 
strikes,  and  dominate  maneuver. Second,  Sullivan  wrote 
about  the  impact  that  information  technology  could  have  on 
warfare,  and  he  tried  to  incorporate  technology  into  the 
Arm^s  organization  and  doctrine.  In  March  1992,  Sullivan 
announced  his  plan  for  the  “Louisiana  Maneuvers” — 
borrowing  on  General  Marshall’s  and  Greneral  McNair’s 
1940-41  organizational  studies  of  the  same  name — ^which 
were  to  be  a  series  of  exercises: 

to  shake  out  emerging  doctrine,  to  experiment  with 
organizational  design,  to  train  the  mobilizing  force,  to  provide 
insights  on  materiel  requirements,  and  to  develop  leaders. . . . 

My  goal  is  to  posture  our  Army  to  protect  the  nation’s  enduring 
interests  in  an  uncertain  future.  I  believe  we  can  accomplish  our 
objectives  by  harnessing  the  power  of  the  microprocessor.  .  .  . 
Louisiana  Maneuvers  will  be  the  laboratory  in  which  we  learn 
about  the  Army  of  the  21st  Century. 

Over  the  next  2  years,  Sullivan  crystaUized  his  ideas  about 
the  structure  that  a  reorganized  Army  would  need.  In  July 
1993,  he  published  the  Army  Enterprise  Strategy,  an 
assessment  of  existing  C^I  systems  and  a  comprehensive 
vision  for  the  Army’s  role  in  the  joint  program  “C^I  for  the 
Warrior.”  The  Enterprise  Strategy  articulated  nine  specific 
actions  for  reshaping  Cold  War  era  information  and 
communications  systems.^^^  In  March  1994,  he  published  a 
campaign  plan  for  Force  XXI,  which  argued  that  the  Army 
needed  to  embrace  the  power  of  information  technology  and 
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implement  the  current  RMA.  “The  high  ground  is 
information.  Today,  we  organize  the  division  around  killing 
systems,  feeding  the  guns.  Force  XXI  must  be  organized 
around  information — ^the  creation  and  sharing  of  knowl¬ 
edge  followed  by  unified  action  based  on  that  knowledge 
which  will  allow  commanders  to  apply  power  effectively. 

In  this  campaign  plan,  Sullivan  argued  that  the  focus  on 
information  might  require  a  redesign  of  the  force  at  all 
echelons.  “That  is  a  very  broad  charter,  and  it  is  by  no  means 
clear  that  we  need  to  make  a  radical  shift.  But  it  is  clear  that 
we  must  open  our  minds  to  the  power  of  change  and  ask 
ourselves:  What  could  be?’”^®^  In  Sullivan's  view,  the  21st 
century  Army  would  need  to  be  more  versatile  and 
strategically  deployable.  Units  would  need  to  rely  on 
electronic — rather  than  geographic  or  physical — 
connectivity,  and  battle  command  would  be  based  on 
“real-time,  shared,  situational  awareness.”  Units  may  come 
in  a  different  shape  and  size,  with  a  lower  leader-to-led 
ratio,  but  “responsibility  will  remain  hierarchical  and 
cannot  be  distributed,”  Reorganization  would  eventually 
affect  all  echelons,  but  it  would  begin  with  the  division,  the 
basic  building  block  of  the  ground  force  structure  in  the 
information  age.  “The  core  competency  of  the  division  as  an 
echelon  is  command  and  control  .  .  .  the  division  is  about 
battle  command  and  . . .  battle  command  is  about  decisive 
victory — dominating  battle  space.”^®® 

The  impact  of  the  Force  XXI  campaign  plan  on  the 
Arm/s  organization  and  doctrine  was  significant.  With  this 
document,  Sulhvan  commissioned  a  review  of  the  division's 
organizational  structure,  with  the  plan  to  carry  this  review 
to  other  echelons  of  the  force.  Sullivan  named  Franks  at 
TRADOC,  in  cooperation  with  the  other  major  commands, 
to  lead  this  redesign  called  “Joint  Venture.”  Moreover, 
Sullivan  assigned  the  DSCOPS  with  the  task  of 
institutionalizing  some  of  the  Louisiana  Maneuvers  lessons 
learned  in  Battle  Labs,  test  beds  to  update  the  various 
battlefield  functions  which  were  located  with  each  branch's 
school.  Each  Battle  Lab's  research  would  culminate  in  an 
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Advanced  Warfighting  Experiment  (AWE).  Finally,  to  effect 
the  acquisition  and  assimilation  of  technology,  Sulhvan 
created  the  Army  Digitization  Office  (ADO)  to  serve  as  the 
integrating  mechanism  for  technology  procurement  and 
implementation.  ADO’s  creation  was  eidianced  by  the  publi¬ 
cation  of  the  Army  Enterprise  Strategy  Implementation 
Plan,  which  provided  a  coherent  structure  to  the  previous 
year’s  Enterprise  Strategy  and  established  the  Horizontal 
Technology  Integration  (HTI)  initiative. 

One  reason  for  Force  XXI’s  “success”  was  General 
Franks,  who  understood  and  agreed  with  Sullivan’s  vision. 
Just  as  Starry’s  experiences  commanding  V  Corps  colored 
his  tenure  as  TRADOC  commander,  so,  too,  did  Franks’ 
experiences  in  DESERT  STORM.  Most  importantly,  Franks 
brought  with  him  a  desire  to  fix  battlefield  C^I.  On  February 
7,  1992,  Franks  directed  CAC  to  “review  in  detail  and 
validate  architecture  requirements,  programs  and 
systems,  with  emphasis  on  mobile  operations,  in  light  of 
the  need  for  a  versatile,  down-sized,  post-Cold  War  Army.” 
This  study,  initially  intended  as  an  abbreviated  functional 
area  assessment  of  the  tactical  systems,  became  a 
broader  look  to  address  the  senior  Army  leadership’s 
dissatisfaction  with  progress  on  ATCCS  and  its  funding.  In 
its  ATCCS  reevaluation,  the  Army  determined  that  it 
needed  a  new  vision  to  meet  commanders’  requirements  in 
the  Information  Age.  If  ATCCS’  goal  was  communications 
integration,  “it  needed  to  become  more  commander  centered 
and  commander  supporting ...  to  integrate  several  kinds  of 
information,  including  near  real-time,  fused,  relevant 
fnendly  and  enemy  information,  and  needed  to  provide 
user-friendly  methods  of  applying  or  manipulating 
information.”^®® 

As  a  result  of  this  study,  CAC  created  the  Force 
Projection  Army  Command  and  Control  (FORCPAC^) 
Action  Plan  to  implement  the  study’s  objectives. 
FORCPAC^  sought  to  create  a  technological  foimdation  for 
the  Arm3r’s  new  mission  of  force  projection — seamless  global 
connectivity.  To  become  truly  seamless,  however,  the  Army 
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needed  to  overcome  its  entrenched  pattern  of  stovepiped 
systems.  FORCPAC^  recommended  creating  integrated 
capability  requirements  and  developing  common  software 
languages,  standards,  and  protocols  as  part  of  the  HTI 
initiative.  In  other  words,  FORCPAC^  recommended 
(re)inventing  the  Sigma  Star-era  interoperability  vision. 
FORCPAC^  also  called  for  the  Army  to  move  towards  a 
commercial  "common  operating  environment,”  using 
commercial  hardware  with  common  operating  systems, 
application  software,  and  information  databases.  This 
standard,  called  the  Defense  Information  Infrastructure 
Common  Operating  Environment,  was  to  use  common 
off-the-shelf  technology,  which  would  not  only  establish 
economies  of  scale  but  create  interoperability  between 
various  defense  contractors.^®^ 

Concurrently,  officers  within  CAC's  Combat  Develop¬ 
ments  section  (CAC-CD)  worked  to  define  "battle 
command,”  the  term  to  which  Sullivan  and  Franks  had 
become  attached.  They  settled  on  "the  expression  of  the 
commander’s  will,  the  way  he  formed  his  vision  of  the  battle, 
how  he  was  helped  in  fully  picturing  it,  and  how  he 
anticipated  and  adjusted  as  information  and  events 
unfolded.”^^®  This  idea  became  the  core  concept  of  the  Battle 
Lab,  a  spin-off  from  CAC-CD.  This  lab  morphed  into  the 
Command  and  Control  Battle  Lab  and  then  into  the  Battle 
Command  Battle  Lab.  As  CAC  historians  argue,  "in  the 
process,  more  than  the  name  changed.  The  Battle  Lab 
changed  from  ‘tinkering  with  the  hardware’  to  stud3ing, 
experimenting  with,  and  developing  the  ‘art’  of  Battle 
Command.”^^^ 

Finally,  in  September  1993 — 2  months  after  Sullivan 
published  the  Army  Enterprise  Strategy — Franks  com¬ 
pleted  a  major  review  of  the  Army  Command  and  Control 
System  (ACCS),  the  Army^s  major  C^  architecture  that 
spans  from  national  to  tactical  levels  and  includes  ATCCS. 
Despite  unanimous  agreement  that  the  ATCCS  vision  from 
the  Cold  War  was  outdated,  the  Army  feared  Congress 
would  abandon  the  old  ATCCS  approach  after  investing 
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decades  of  time  and  billions  of  dollars  and  not  pay  for  a  new 
initiative.  Therefore,  Franks  chose  to  recast  ATCCS  with  its 
various  components'  funding  lines  into  a  new  integrated 
funding  under  a  new  name,  the  Army  Battle  Command 

System  (ABCS).'^2 

Under  Franks'  plan,  ABCS  should  provide  seamless 
connectivity  from  the  squad  level  to  the  National  Command 
Authority  using  Army,  joint,  and  aUied  communications 
standards.  (See  Figure  3.)  At  the  highest  level,  ABCS 
comprises  the  Army  Global  Command  and  Control  System 
(AGCCS),  which  operates  at  the  corps  and  theater  levels 
and  overlaps  with  the  Joint  GCCS.  ATCCS  operates  in  the 
middle  echelons,  from  corps  to  battalion.  The  system 
operating  at  the  lowest  echelons — called  the  Force  21  Battle 
Command  Brigade  and  Below  (FBCB2)  and  recently  tested 
in  the  EXFOR  AWE— will  span  from  brigades  to  individual 
soldiers  via  a  tactical  internet  and  applique — ^French  for 


Figure  3.  Army  Battle  Command  and  Control 

System. 
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“applied’’ — computers  added  to  individual  weapons. 
ABCS  embraces  the  “single  point  of  entry”  concept,  so  that 
once  data  has  been  captured  in  digital  form,  it  can  be  shared 
“across  echelons  and  geographic  boundaries  without  being 
retyped  or  otherwise  reentered.”^^^  Thus,  the  system  should 
permit  commanders  at  every  level  to  share  a  common 
picture  of  the  battlefield,  scaled  to  their  level  of  interest  and 
tailored  to  their  special  needs. 

As  the  successor  to  ATCCS,  ABCS  was  to  continue  the 
“evolutionary  acquisition” — spiral  development — strategy 
of  ATCCS  development  and  procurement.^^®  However, 
Sulhvan  realized  that  to  create  an  integrated  system,  it 
needed  to  be  under  the  control  of  one  individual  who  would 
have  the  authority  to  standardize  and  compromise  between 
different  systems  and  different  contractors.  In  July  1993, 
Sulhvan  appointed  then  Major  General  Wilfiam  Campbell 
as  director  of  the  Program  Executive  Office  for  C^, 
responsible  for  development  and  acquisition  of  command, 
control,  communications,  and  computers.^^®  By  unifying 
many  disparate  programs  under  Campbell  and  tasking  him 
with  the  Battle  Command  AWE,  Sulhvan  streamlined  the 
bureaucracy  surrounding  battlefield  C^. 

Under  Campbell,  numerous  systems  comprising 
ABCS — ^including  the  five  ATCCS  systems  at  various  stages 
of  development — ^have  been  fielded  to  the  4th  Infantry 
Division,  the  Experimental  Force  (EXFOR)  division  created 
at  Ft.  Hood.  The  Army’s  strategy  for  digitizing  the 
battlefield  uses  a  bottom-up  approach  that  experiments 
echelon  by  echelon  with  several  systems  simultaneously 
and  involves  brigade-,  division-,  and  corps-level  experi¬ 
ments.  The  Army  sponsored  a  company-level  AWE  in  1993 
and  a  battahon-level  AWE  in  1994  at  Ft.  Hood.  In  March 
1997,  EXFOR  conducted  a  brigade-level  AWE  at  the 
National  Training  Center  (NTC),  and  it  held  a  division-level 
AWE  in  November.  Final  plans  for  the  digitized  division  and 
corps  force  structures  should  be  completed  early  in  1998. 
The  Army  then  plans  to  field  its  first  “digital  division”  by 
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2000;  by  2004,  the  Army  hopes  to  field  three  digital  divisions 
as  part  of  the  first  digital  corps.^^^ 

At  the  2-week  brigade  AWE  in  March  1997,  the  Army 
tested  ABCS  and  72  other  prototypes,  many  of  them 
applique  systems. Major  Marcus  Sachs,  the  4th  ID^s 
automation  management  officer,  said  the  EXFOR 
brigade — equipped  with  87  different  digital  systems — ^had 
more  than  800  devices  with  internet  protocol  (IP)  addresses. 
Of  these,  more  than  75  percent  were  applique  computers  on 
individual  weapon  platforms  or  hand-held  by  infantrymen. 
Although  the  EXFOR  faced  the  NTC’s  opposing  forces 
(OPFOR)  in  the  war  game,  the  purpose  of  the  AWE  was  to 
work  out  kinks  in  the  systems.  Therefore,  the  battlefield 
was  relatively  static,  without  cross-attacking  units  or 
relocating  (“jumping’")  command  posts. 

Many  of  the  appliques  were  applied  in  a  temporary 
manner  for  the  experiment;  for  example,  the  computer  in 
the  Abrams  tank  was  mounted  so  that  the  crew  could  not 
fire  its  main  gun — ^because  it  would  recoil  onto  the  LCD 
display.  Similarly,  at  its  current  stage  in  development, 
FBCB2  passes  messages  in  a  hierarchical  manner  (for 
example,  all  of  the  tanks  in  a  platoon  must  communicate 
their  locations  through  their  platoon  leader’s  and  company 
commander’s  tanks).  Therefore,  although  applique  in 
theory  should  be  able  to  identify  friendly  vehicles  as  “dead” 
or  “ahve,”  during  the  brigade  AWE  some  “dead”  platforms 
(such  as  a  “dead”  company  commander’s  tank)  kept  their 
applique  systems  active  in  order  to  relay  messages  for  the 
tactical  internet. 

Initial  AWE  reviews  were  mixed.  According  to  an 
Operational  Test  and  Evaluation  Office  observation  team, 
“there  was  no  increase  in  lethality,  survivability  or 
operational  tempo  attributable  to  digitization.”  OT&E  also 
suggested  that  fratricide  may  have  been  higher  during  the 
experiment:  there  were  32  incidents  of  fratricide  during  the 
AWE  compared  to  a  combined  total  of  28  for  the  three 
previous  conventional  NTC  exercises.  Moreover,  electronic 
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warfare  officers  in  the  OPFOR  said  they  could  “detect  and 
locate”  EXFOR’s  tactical  operations  centers  “twice  as  fast” 
as  they  could  those  of  conventional  brigades  training  at 
NTC.12' 

TRADOC  Commander  General  William  Hartzog 
dismissed  these  findings,  claiming  that  the  EXFOR’s 
performance  was  “at  least  as  good,  and,  in  some  cases, 
much,  much  better”  than  the  three  task  forces  whose  NTC 
rotations  proceeded  the  AWE.  Hartzog  said  much  of  the 
fratricide  increase  occurred  because  the  EXFOR  fought  6 
days  longer  than  an  average  NTC  rotation  and  had  at  least 
1,800  soldiers  more  than  most  task  forces.  And  in  terms  of 
electronic  vulnerability,  the  EXFOR  did  better  than 
anticipated,  Hartzog  said,  and  the  Army  has  enough  money 
to  fix  the  problems  within  2  years.^^^ 

Although  the  Army  will  compile  official  lessons  learned 
over  the  next  few  months,  six  conclusions  from  the  AWE  can 
already  be  drawn.  First,  ABCS  has  the  potential  to  “lift  the 
fog  of  war.”  In  an  April  14, 1997,  message  to  general  officers. 
Army  Chief  of  Staff  Dennis  Reimer  estimated  that  EXFOR 
was  able  to  use  its  sensors  and  other  communications  tools 
to  see  the  battlefield  correctly  80  percent  of  the  time.^^^  As  a 
result,  the  battlefield  picture  on  ABCS  usually  captured  95 
percent  of  the  “true”  picture  as  seen  on  the  NTC  controllers’ 
simulation  control  system  (“Star  Wars”).  One  reason  for  this 
high  level  of  accuracy  was  the  successful  integration  of  the 
Global  Positioning  System  (GPS)  into  the  tactical  internet. 
A  weapon  platform  (or  an  individual  soldier  with  a 
hand-held  computer)  would  automatically  transmit  its 
location  in  three-dimensional  space  after  100  meters  of 
movement  or  two  minutes,  whichever  occurred  first.  Within 
seconds,  this  data  would  be  propagated  as  an  icon  graphic 
on  the  battlefield  map  in  all  ABCS  systems,  from  individual 
tanks  to  the  division  command  center. 

Second,  despite  this  immense  improvement  in 
situa-tional  awareness,  technology  may  point  to  a  variety  of 
inadequacies  in  doctrine.  According  to  Basil,  in  one  battle. 
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the  EXFOR’s  unmanned  aerial  vehicle  (UAV)  showed  the 
OPFOR  still  massed  in  its  assembly  area,  a  perfect  target 
for  an  artillery  strike.  Yet  it  took  the  EXFOR  40  minutes  to 
call  for  fire,  by  which  time  the  OPFOR  had  already  moved. 
“They  should  have  had  fire  on  it  in  30  seconds,  but  the 
soldiers  weren’t  trained  on  what  to  do  with  all  of  this 
data.”^^^  Although  trained  in  the  system’s  electronic 
procedures,  EXFOR  soldiers  went  into  the  AWE  less  trained 
in  exploiting  its  potential.  A  related  problem  was  that 
commanders  did  not  always  trust  their  computer  displays, 
but  instead  went  with  their  intuition.  As  Major  Jerry 
Bradshaw  expressed  it,  “Just  because  you  have  the  picture 
in  front  of  you  doesn’t  mean  that  the  reaction  is 
automatic.”^^®  On  the  other  hand,  the  technology  provided  a 
certain  amount  of  comfort: 

[When]  talking  to  a  soldier  about  the  applique  and  the  new 
digital  tools  at  his  disposal,  the  soldier  stated  that  he  feels  much 
more  comfortable  now,  especially  at  night,  driving  alone  in  the 
desert.  With  his  applique  on  and  operational,  he  is  no  longer 
“alone.”  “I  can  see  all  of  my  other  soldiers  there  on  the  screen  and 
know  that  Fm  not  really  all  by  myself  in  the  middle  of 
nowhere.”^^ 

Third,  ATCCS  worked  relatively  well.  Sachs  said  that  it 
was  possible  to  log  onto  one  system  and  pull  information  up 
via  the  client-server  on  another  system.  However,  graphic 
overlays  from  one  terminal  cannot  be  edited  on  another,  and 
problems  remain  with  message  formats,  especially  in  the 
CSSCS.  In  many  cases,  the  ATCCS  systems  would  only 
populate  the  higher  headquarters’  computers  if  a 
subordinate  computer  sent  a  manual  message.  This  creates 
problems  for  the  lower-echelon  commanders  who  are  trying 
to  fight  the  battle  and  do  not  have  time  to  update  the  system 
electronically.  This  also  slows  the  real-time  picture  of  the 
battlefield,  because  only  correctly  formatted  messages  will 
automatically  propagate  the  common  database.  Any 
messages  with  incorrect  formats  must  be  manually  entered 
into  the  database,  which  slows  the  process  considerably. 
One  intelligence  analyst  who  worked  in  the  EXFOR  tactical 
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command  post  (TAG)  said  that  the  battlefield  picture  was 
frequently  two  hours  behind  due  to  the  unprocessed 
message  backlog. 

Perhaps  the  largest  ATCCS  problem  was  with  fire 
control  in  AFATDS.  During  the  last  battle,  the  OPFOR 
destroyed  all  of  the  friendly  UAVs,  although  the  EXFOR 
tried  to  call  in  a  fire  mission  to  kill  the  OPFOR's 
surface-to-air  missiles.  Unfortunately,  the  fire  missions 
were  never  shot,  because  SA-8s  were  low  on  the  priority  of 
fires  list  and  therefore  automatically  denied  by  the 
computer.  This  vignette  had  a  big  impact  on  the  EXFOR,  as 
one  observer  noted, 

I  think  that  we  as  a  community  got  caught  up  in  the 
capabilities  of  the  system  and  what  it  could  do  if  those  pesky 
humans  weren’t  around  to  get  in  the  way.  What  we  need  to 
remember  is  that  the  box  is  (or  should  be)  designed  to  be  a  tool 
for  the  commander . . .  with  real  tactical  experience  to  use.  The 
picture  on  the  screen  is  useless  without  the  experience  to 
interpret  it  and  make  the  right  judgment  based  on  the 
information  presented.^^® 

Fourth,  a  surplus  of  data  does  not  necessarily  equal 
knowledge.  With  such  a  high  dependence  on  graphics, 
which  require  lots  of  digital  memory,  the  ABCS  network 
experienced  significant  bandwidth  problems  and 
communications  chokepoints,  as  some  links  could  only  pass 
data  at  a  9.6  baud  rate.  Although  ATCCS  can  finally  do  in 
1997  what  it  was  conceived  to  do  in  1979 — digitally  pass  the 
five-paragraph  operations  order — ^it  took  several  hours  to 
get  the  order  down  to  the  battalion  level  over  such  slow 
communications  paths.  ASAS  crashed  in  the  first  battle, 
presumably  because  of  an  information  overflow  in  the 
network.  \^en  this  occurred,  the  analysts  reached  for  their 
trusted  tools:  paper  maps,  acetate  overlays,  and  colored 
markers.^^®  As  Sachs  wrote,  “It’s  a  digital  traffic  jam  out 
there  now.  Information  discipline  has  gone  to  hell.  It’s  quite 
possible  that  we  are  going  to  have  to  learn  to  communicate 
on  the  battlefield  using  the  digital  equivalent  of  a  point 
paper.  Simpler  graphics  will  have  to  suffice.”^^^  Perhaps  the 
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most  eloquent  expression  of  this  problem  came  from 
Captain  Leaphart: 

We  have  created  an  insatiable  appetite  for  data.  This  may  be 
insurmountable  without  a  serious  shift  in  philosophy  on  the 
part  of  senior  level  commanders.  They  want  more  data.  We  have 
continued  to  roll  over  for  their  demands  of  more  data  without 
forcing  them  to  distill  those  demands  into  the  real  information 
requirements  they  need  to  operate.  Data  and  information  are 
NOT  the  same  thing!^®^ 

Fifth,  EXFOR  further  extends  a  developing  dependence 
on  contractors,  which  raises  questions  about  the  Army’s 
abihty  to  support  ABCS  autonomously.  This  reliance  on 
civihan  contractors  has  raised  considerable  debate  about 
personnel  issues.  According  to  Sachs,  one  plan  being 
considered  is  to  create  an  organization — ^headed  by  a 
heutenant  colonel  and  comprised  of  deployable  contractor 
teams— which  would  provide  all  digital  support  for  III 
Corps  if  any  of  its  subordinate  units  were  to  deploy. 

Finally,  the  AWE  is  being  touted  as  an  experiment  in 
acquisition  reform;  as  former  Secretary  of  Defense  William 
Perry  said  during  a  visit  to  Ft.  Hood  in  November  1996,  “this 
[acquisition  reform]  has  importance  well  beyond  the 
Army.”^^^  What  exactly  is  this  reform  in  the  development 
and  acquisition  process?  The  Army  has  brought  together 
contractors,  TRADOC  developers,  4th  ID  soldiers,  AMC 
acquisition  officials,  and  ABCS  program  officers  to  create 
the  Central  Technical  Support  Facility  at  Ft.  Hood.  By 
placing  all  of  the  Force  XXI  systems  in  one  building, 
“marr3dng  up”  the  real  users  with  the  contractors,  and 
running  24  hour  operations,  “in  2  years  the  Army  was  able 
to  accomplish  what  it  usually  does  in  6.” 

The  arrangement  showed  benefits  soon  after  Force  XXI’s 
connectivity  exercise.  Soldiers  discovered  that  the  ITT-built 
SINCGARS  radios  squealed  when  in  use  and  had  a  shorter 
range  than  specified  when  voice  and  data  were  sent  over  the 
same  channel.  ITT  contractors  returned  to  their  lab  and  6 
weeks  later  delivered  1,600  new  radios  which  operated  to 
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the  standards  the  Army  required.  Such  an  accomplishment 
usually  takes  3-4  years,  according  to  Colonel  Thomas  Metz, 
director  of  the  EXFOR  Coordination  Cell  and  4th  ID  chief  of 
staff.  According  to  Sachs,  this  is  a  new  approach,  because 
the  Army  develops  and  fields  a  20  percent  solution  and  then 
gets  immediate  feedback  before  developing  any  further. 
“This  way  we  can  field  equipment  much  more  quickly  and 
give  the  Army  what  it  really  wants,”  Sachs  explained.^^^  In 
other  words,  the  Army  has  returned  to  spiral  develop¬ 
ment — “evolutionary  development” — as  conceived  in  Find, 
Fix,  and  Test  for  TACFIRE  in  1973. 

In  sum,  since  DESERT  STORM  and  the  end  of  the  Cold 
War,  the  Army  has  made  some  progress  in  fielding 
technology,  although  it  has  not  made  similar  progress  in 
addressing  the  overall  problem.  Fundamentally,  ATCCS 
and  ABCS  are  still  trying  to  solve  the  old  dilemma  from  the 
Sigma  Star  era — ^how  to  lift  the  fog  of  war  and  speed  up  the 
friendly  OODA  cycle.  Second,  the  perpetual  tug-of-war 
between  the  developmental/testing  and  user  communities 
continues  to  plague  Army  digitization  efforts.  However,  the 
post-Cold  War  geopolitical  situation  and  a  turnover  in 
senior  Army  leadership  have  again  shifted  the  balance 
towards  the  users. 

Sullivan’s  Force  XXI  had  the  same  impact  on 
technological  development  and  acquisition  as  Starry’s 
AirLand  Battle  and  Army  86  programs.  By  empowering 
TRADOC  and  DCSOPS  with  force  structure  experimen¬ 
tation  and  information  technology  integration,  Sullivan 
effectively  moved  resources  and  responsibility  for 
innovation  away  from  the  developmental  and  testing 
communities  to  the  user  community.  The  Battle  Labs — ^the 
functional  equivalent  of  TACIP  a  decade  later- — were  an 
effort  to  hyipsiss  the  bureaucratic  ossification  of  the  weapons 
system  development  process  and  its  many  actors  and  to  give 
innovation  leadership  and  initiative  back  to  CAC,  the 
nominal  voice  for  the  user  community.  Franks  articulated 
Sulhvan’s  vision  for  Army  systems  by  recycling  the 
ATCCS  program  as  ABCS,  while  Campbell  pulled  the  C^I 
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effort  together  into  a  single  program,  thereby  minimizing 
interoperability  problems.  As  with  'Tront-end  evolution”  in 
the  early  1980s,  the  user  community — ^through  DCSOPS — 
has  been  driving  the  innovation  and  experimentation  in  the 
AWE.  Thus,  while  the  five  ATCCS  systems  still  remain 
under  different  program  managers  and  contractors,  they 
have  made  progress  during  the  AWEs  and  should  transition 
to  a  common  operating  environment  within  the  next  3 
years.^^^ 

Conclusions. 

But  is  ATCCS  an  innovation?  Has  ABCS  successfully 
implemented  the  Revolution  in  Military  Affairs?  According 
to  Sullivan  in  1995,  the  answer  to  these  questions  is  yes: 

The  U.S.  Army  is  responding  to  the  ongoing  revolution  in 
military  affairs.  Force  XXI  is  the  Army’s  vehicle  to  create  a 
paradigm  for  building  a  21st  Century  Army  which  anticipates 
and  leverages  the  changes  inherent  in  this  revolution.  The 
name  “Force  21"  represents  .  .  .  three  things:  (1)  a  new 
conceptual  construct  about  creating  and  fielding  the  entire 
force,  (2)  a  process  for  implementing  this  fundamentally  new 
concept,  and  (3)  an  open-ended  series  of  successively  improved 
versions  of  the  Army.  .  .  .  The  Army’s  Force  XXI  strategic 
objective  captures  the  essence  of  the  required  changes  described 
above:  to  transform  itself  from  an  industrial- age  Army  to  a 
knowledge  and  capabilities-based,  power  projection  Army 
which  can  achieve  land  force  dominance  across  the  full 
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continuum  of  21st  Century  military  operations. 

In  Sullivan’s  view.  Force  XXI  is  an  innovation  because  it 
changes  not  only  the  structure  of  the  organization  but  also 
the  process  by  which  the  organization  will  continue  to 
change  in  the  future.  For  that  reason — applying  Sullivan’s 
own  definition  to  the  case — I  disagree.  As  this  paper  has 
suggested,  the  intellectual  concepts  behind  ABCS  and  the 
^‘new  evolutionary  approach”  to  developing  automated 
systems  have  been  around  since  TACFIRE  and  TOS. 
Moreover,  the  tension  between  the  user  community  and  the 
developmental/testing  communities  has  not  abated,  and  the 
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tug-of-war  between  proponents  of  the  waterfall  and  spiral 
development  methods  continues.  The  Army  is  aware  of 
these  problems.  In  congressional  testimony  in  1992, 
then-Assistant  Secretary  of  the  Army  for  Research, 
Develop-  ment,  and  Acquisition  Stephen  K.  Conver 
explained  to  lawmakers  in  an  insightful  statement: 

If  we  are  to  have  successful  programs,  we  believe  we  must 
resolve  requirements  issues  between  the  users  and  developers 
before  we  start  any  program.  We  have  observed  that  when  our 
acquisition  programs  run  into  problems,  the  cause  has  often 
been  a  disconnect  between  the  user’s  requirement  and  the 
acquisition  strategy  that  was  adopted  (or  the  technology  that 
was  available)  to  meet  that  requirement.  These  problems  take 
three  forms:  (1)  overreaching — expecting  the  acquisition 
system  to  deliver  results  that  are  not  achievable;  (2) 
overspecing — burdening  the  acquisition  strategy  and  the 
contractor  with  too  much  emphasis  on  ‘Tiow”  to  meet  the 
requirement  and  not  allowing  some  flexibility;  and  (3) 
push! pull — the  reluctance  of  some  users  to  accept  new 
technology  that  must  be  "pushed”  or  sold  to  them,  in  contrast 
to  the  familiar  technology,  which  they  willingly  “pull”  into 
their  organization,  (emphasis  in  original)^^® 

Yet  as  Salisbury  said  in  his  TACFIRE  study,  “Many  lessons 
learned’  have  come  out  of  the  TACFIRE  program. 
Unfortunately,  lessons  learned  too  often  become  lessons 
forgotten.  The  Army  falls  short  in  its  ability  to  retain  a 
corporate  memoi^  and  is  frequently  doomed  to  repeat  its 
past  mistakes.”^^^ 

Sullivan’s  Force  XXI,  ABCS,  and  Battle  Labs  are  new 
ways  of  putting  together  ideas  that  have  been  extant  for 
several  decades.  ATCCS  had  the  potential  to  be  a  successful 
innovation  when  it  was  originally  conceived  as  Sigma  Star 
in  1978,  had  technology  been  able  to  support  the  concept 
and  had  it  not  become  mired  in  the  bureaucratic  tension 
between  the  user  and  developmental/testing  communities. 
At  its  core,  Sigina  Star,  ATCCS,  and  ABCS  shared  a 
dream — to  minimize  the  “fog  of  war,”  or  in  the  jargon  of  the 
current  RMA,  to  maximize  the  friendly  OODA  cycle.  Yet  20 
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years  after  its  conception,  implementation  and  execution 
are  still  flawed.  In  this  regard,  Starry  and  Sullivan  shared 
an  organizational  savvy — both  leaders  were  able  to 
articulate  the  practitioners’  finstration  with  a  deliberate 
developmental  process  that  fielded  systems  several 
technological  generations  late.  Both  leaders  were  able  to 
engage  the  user  community,  shift  resources  and  responsi¬ 
bility  to  it,  and  thereby  neutralize  the  developmental 
bureaucracy.  As  this  case  suggests,  the  military  is  not  a 
unitary  actor,  and  one  individual  alone  cannot  override  a 
large  bureaucracy.  To  his  credit,  Sullivan  may  have  realized 
that  he  could  accomplish  only  so  much  during  his  term  as 
Army  Chief  of  Staff.  To  ensure  a  Force  XXI  “legacy,” 
Sullivan  needed  to  structure  the  debate  so  that  it  would 
outlive  his  tenure — ^he  needed  to  raise  questions  and  begin 
experiments  that  could  not  be  easily  undone  in  the  future  by 
his  successors  or  the  organization  as  a  whole. 

Nonetheless,  neither  Starry  nor  Sullivan  enacted  a 
“military  innovation”  as  defined  in  the  first  section  of  this 
paper.  Despite  the  attempts  at  digitizing  the  battlefield,  the 
Army  has  not  yet  altered  its  core  tasks  nor  displaced  any  of 
its  combat  platforms.  While  AirLand  Battle  in  1978  and 
Force  XXI  in  1994  required  highly  sophisticated  C^I 
systems  and  weapons  platforms,  at  a  deeper  level,  very  little 
has  changed.  On  the  contrary,  the  technology  is  literally 
being  “applied”  into  the  current  weapons  platforms.  As 
Cohen  correctly  points  out, 

When  the  Clinton  administration  formiilated  its  defense  policy 
in  1993,  it  came  up  with  the  Bottom-Up  Review,  which  provided 
for  a  force  capable  of  fighting  simultaneously  two  regional  wau*s 
assumed  to  resemble  the  Gulf  War  of  1991.  By  structuring  its 
analysis  around  enemy  forces  similar  to  those  of  Iraq  in  that 
year — armor-heavy,  with  a  relatively  large  conventional  but 
third-rate  air  force — ^it  guaranteed  a  conservatism  in  military 
thought. .  . .  For  this  reason,  among  others,  the  revolution  will 
take  far  longer  to  consummate.^'^ 

Combat  arms  officers  support  the  technology  because  it 
provides  information  dominance  “sensor  to  shooter”^'^^ — ^the 
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fused  information  passes  almost  simultaneously  from  the 
collection  platforms  to  the  weapons  platforms,  virtually 
bypassing  the  staff. 

In  this  regard,  Force  XXI  is  helping  the  Army  to  leverage 
new  technology  to  improve  its  current  way  of  doing 
business.  Force  XXI  and  the  C^I  systems  which  comprise 
ABCS  focus  on  conventional  regional  aggressors.  How  the 
“digitized’’  Army  expects  to  fight  in  the  21st  century  seems 
suspiciously  like  armored  combat  against  the  Warsaw  Pact 
with  new  technology  grafted  on.  As  one  AWE  participant 
noted,  ‘We  don’t  do  a  good  job  of  automating  processes.  We 
automate  tasks.  For  example,  we  automate  the  task  of 
producing  an  overlay,  but  not  the  process  of  producing  a 
course  of  action.  Consequently,  machines  are  never  used  to 
the  full  extent  of  their  capabilities. 

Therefore,  in  my  view,  ATCCS,  its  predecessors,  and  its 
successors  belong  to  a  “military  technological  revolution”  in 
which  technology  is  employed  in  an  evolutionary  manner, 
without  causing  major  doctrinal  or  organizational  change. 
We  have  witnessed  the  impact  of  information  technology  on 
warfare,  but  we  have  not  yet  seen  the  subsequent 
transformation  of  operations  and  organization.  Without 
significant  organizational  or  doctrinal  change,  these 
battlefield  C'^I  systems  cannot  embody  the  postulated  RMA. 
As  Mazarr  warns  in  his  most  recent  article  about  the  RMA: 

This  incrementalist  notion  of  the  RMA  is  ultimately 
self-defeating.  It  violates  the  common  strategic  principle  that 
a  period  of  rapid  change  is  the  time  to  think  comprehensively 
rather  than  narrowly.  It  indefinitely  postpones  the  day  when 
the  U.S.  military  will  depart  from  deeply  entrenched 
evolutionary  doctrines  and  routines  and  embrace  the  truly 
revolutionary  elements  of  the  new  era  in  warfare.^^ 

The  information  revolution  as  conceived  in  the  4th  Infantry 
Division  exists — ^in  Sullivan’s  own  words — “to  apply  power” 
with  the  old  weapons  to  a  high-intensity  predominantly- 
armored  threat. 
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Given  that  ATCCS  and  ABCS  do  not  embody  the 
currently  postulated  RMA,  perhaps  it  is  valid  to  ask 
whether  the  RMA  is  actually  capable  of  being  accom¬ 
plished — especially  given  the  bureaucratic,  political,  and 
budgetary  constraints  in  which  the  U.S.  armed  forces  have 
to  operate.  I  am  not  sure.  In  the  current  civil-military 
environment — where  every  “revolutionary”  idea  faces 
organizational  pressures  from  within  the  government, 
military  services,  and  their  supporting  contractor 
communities — an  RMA  which  simultaneously  synthesizes 
technological  and  doctrinal  innovation  is  unlikely  to  occur. 
Perhaps  military  theorists  have  set  the  bar  too  high  for 
service  decisionmakers,  program  heads,  and  budget 
officers.  Perhaps  the  RMA  is  an  idealized  construct  rather 
than  a  feasible  goal. 

Nonetheless,  to  think  about  the  information  revolution 
in  a  comprehensive  way  would  be  to  ask  with  what  and 
against  what  should  the  Army  be  applying  power?  The 
Army  still  has  the  potential  to  capitalize  on  the  postulated 
RMA,  albeit  not  on  its  current  developmental  path.  There 
are  three  possible  ways  in  which  the  Army  could  embrace 
the  new  technology  and  radically  alter  its  doctrine  and  core 
tasks. 

First,  the  Army  could  seriously  restructure  its 
organization.  The  civilian  analogue  to  this  period  was  the 
large  down-sizing  and  hierarchical  flattening  about  8  years 
after  the  information  technology  revolution  in  the  corporate 
workplace.  Similarly,  TRADOC  is  conducting  a  “Joint 
Venture”  force  structure  review,  which  could  be  the 
precursor  to  a  parallel  change  in  hierarchy.  Several  officers 
have  postulated  the  way  the  post-Gold  War  Army  should 
look;  perhaps  best  known  is  LTC(P)  Douglas  MacGregor, 
who  argues  that  the  Army  needs  to  move  to  smaller,  more 
mobile  organizations — similar  to  the  combat  commands 
used  during  World  War  ll}^^  Blaker  promulgates  another 
vision,  in  which  the  total  force  structure  would  reflect  the 
new  RMA  technologies.  In  BlakeFs  view,  the  active 
component,  downsized  and  equipped  with  new  capabilities. 
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would  focus  exclusively  on  the  mid-  to  high-level  intensity 
warfighting  missions.  The  reserve  component,  which  would 
retain  most  of  today's  heavy  equipment  and  conventional 
capabilities,  would  take  direct  responsibility  for  all  other 
missions,  including  peace  operations. 

This  debate  parallels  a  similar  force  structure  review  in 
the  1950s,  when  the  Army  developed  its  pentomic  army 
concept  and  eliminated  battalion  commands — and  hence 
the  functional  purpose  of  lieutenant  colonels.  As  with  most 
structural  changes,  the  pentomic  army’s  effects  were  not 
immediately  apparent;  it  was  only  later  that  the  Army 
understood  the  organizational  challenges  created  by 
officers  having  no  troop  contact  between  the  ranks  of  major 
to  colonel.  Similarly,  when  corporate  America  down-sized 
middle  management,  its  effects  were  also  not  immediately 
obvious.  It  was  only  after  the  organization  was  flattened 
that  the  implications  were  fully  understood — eliminating 
middle  management  degraded  organizational  memory  and 
effectively  destroyed  the  mentoring  and  maturation  process 
of  leaders. 

Second,  the  Army  could  seriously  address  the  question  of 
what  future  enemies  will  look  like.  Some  RMA  proponents 
argue  that  the  future  “battlefield”  will  be  empty,  with 
reconnaisance  sensors  and  long-range  precision  strike 
weapons  keeping  opponents  far  apart.  In  this  scenario  close 
combatants  would  be  rarely  used,  brought  in  at  the  end  for 
the  final  \oup  de  grace”  But  I  believe  that  future  warfare 
will  most  likely  be  what  we  used  to  characterize  as  “low 
intensity  conflict”  against  committed,  manpower  intensive, 
low-tech  opponents.  Such  decentralized  threats  could 
increase  if  the  United  States  pursues  its  current  national 
security  strategy  of  engagement  and  preventive  defense.  A 
highly  decentralized  threat,  such  as  we  faced  in  Somalia 
and  Haiti,  mitigates  the  capabilities  of  Force  XXI 
technology. 

A  future  opponent,  conversant  with  the  lessons  of  the  Gulf 

War  and  Vietnam,  might  choose  to  challenge  MTR  technology 
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by  presenting  an  assymetrical  low-tech  strategy,  perhaps  one 
not  energy  based  and  therefore  not  vulnerable  to  most  of  our 
sensors.  Such  a  strategy  would  minimize  communications  and 
electronic  indicators  so  severely  that  there  would  be  very  little 
to  “read,”  Such  a  response  would  effectively  deny  the  ability  to 
employ  many  offensive  MTR  capabilities . . .  Our  own  love  affair 
with  decisive  maneuver,  precision  strike  and  the  ability  to 
synchronize  actions  in  time  and  space  thus  may  not  be  relevant, 
possible  or  even  desirable  for  all  future  opponents.^'^® 

As  we  pursue  technology  to  advance  our  capabilities,  we 
must  be  aware  that  there  are  limits  to  what  technology  can 
do,  especially  in  preventive  defense  missions  and  peace 
operations. 

Third,  the  Army  could  radically  redefine  its 
understanding  of  information  warfare.  This  would  require 
seriously  addressing  the  capabilities  that  information 
technology  can  provide — ^from  a  fresh  perspective.  Some 
analysts  argue  the  information  revolution  is  far  more  likely 
to  equalize  power  between  the  have  and  have-not  countries 
than  to  concentrate  it  still  further  in  the  developed 
countries.  Unlike  nuclear  weapons,  commercial  off-the- 
shelf  technology  is  not  prohibitively  expensive  to  develop 
and  maintain.  Technology  could  disrupt  in  two  ways — 
either  through  the  information  networks  themselves  or 
through  physical  attacks  on  key  nodes.  As  the  world’s  most 
advanced  consumer  and  producer  of  information 
technology,  the  United  States  is  also  the  most  vulnerable. 
On  the  one  hand,  small  states  or  terrorist  organizations 
could  go  after  our  infrastructure  or  the  international 
currency  markets  by  propagating  computer  viruses  or 
hacking  their  way  into  networks.  On  the  other  hand,  such 
organizations  could  plan  physical  attacks  on  key  nodes.  For 
example,  the  entire  East  Coast  railroad  network  could  be 
paralyzed  by  crippling  the  two  computers  which  control 

This  third  line  of  reasoning  presents  another  danger  as 
well.  Simply  put,  other  nations  with  a  clearer  strategic 
purpose  and  less  sunk  capital  at  risk  could  become  leaders 
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in  the  current  RMA.  Despite  notable  progress,  when  we  look 
back,  we  may  see  the  1980-90s  as  a  period  of  unrealized 
potential,  roughly  comparable  to  the  1920-30s,  when 
cavalry  and  infantry  stubbornly  resisted  the  internal 
combustion  engine  for  motorized  warfare.  In  this  regard, 
the  currently  postulated  RMA  is  eerily  similar  to  the  British 
interwar  mechanization  experience. 

Anyone  looking  at  European  military  thinking  between  the 
world  wars  would  have  assumed  that  the  British  or  French 
would  have  been  the  masters  of  the  new  forms  of  warfare.  The 
conceptual  writings  of  people  like  Charles  DeGaulle,  B.  H. 
Liddell  Hart,  and  J.  F.  C.  Fuller  outshone  those  of  their 
German  counterparts.  But  the  Germans,  unlike  the  British, 
empowered  their  visionaries  and  allowed  them  to  restructure 
doctrine,  tactics,  training,  and  all  the  other  elements  of 
military  art.^®^ 

The  U.S.  Army  is  dangerously  close  to  the  same  trap. 
Another  country  might  capitalize  on  an  RMA  first  because  it 
could  start  with  a  clean  slate  and  think  strategically,  while 
the  United  States  will  be  updating  an  outdated  system 
incrementally. 

With  this  comparison  in  mind,  I  argue  that  military 
innovation  is  caused  by  a  challenge  to  the  military’s  existing 
conventional  hierarchy.  This  challenge  can  originate  from 
many  sources — defeat  in  battle,  extreme  budget  cuts, 
organizational  irrelevance  in  light  of  new  technology.  Such 
a  fundamental  challenge  to  the  hierarchy  is  necessary  to 
create  the  conditions  in  which  the  organization  will 
willingly  alter  its  core  tasks — and  even  then,  it  alters  these 
tasks  only  because  it  has  no  other  choice.  After  World  War  I, 
in  victorious  Britain  the  military  hierarchy  remained  in 
charge  and  thus  used  technology  to  update  its  existing 
system  of  waging  war.  In  contrast,  the  defeated  German 
military  had  its  hierarchy  threatened  and  thus  was  willing 
to  develop  a  new  system. 

Even  ATCCS — ^while  not  an  innovation  as  defined  in  this 
paper — ^had  potential  to  be  an  innovative  program:  first  as 
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Sigma  Star  under  Starry  and  then  as  ABCS  under  Sullivan. 
In  both  periods,  the  hierarchy  was  significantly  challenged, 
which  caused  a  shift  in  the  innovative  balance  of  power 
between  the  user  and  developmental/testing  communities. 
Under  Starry,  there  was  a  renewed  awareness  that  the 
smaller,  professional  Army  was  not  capable  of  successfully 
defending  against  the  larger  Soviet  threat.  This  challenge 
gave  rise  to  Sigma  Star  and  AirLand  Battle.  Under 
Sullivan,  the  end  of  the  Cold  War  effectively  eliminated  the 
external  enemy  and  threatened  to  make  the  Army 
irrelevant.  This  challenge  gave  rise  to  ABCS  and  Force  XXI. 
In  neither  case,  however,  was  the  hierarchy  so  challenged  as 
to  force  the  organization  to  embrace  a  new  system  of  waging 
war.  I  argue  that  without  this  factor,  military  innovation 
does  not  occur. 
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